Bugzilla Bug 70838

Here's an interesting bug in app-admin/sudo, that I discovered in the
course of testing StrongBox (a security oriented gentoo-based distro). I
posted it upstream, where there's now a patch available. In brief, any
bash script that is run from sudo is vulnerable to having bash functions
implanted by the original user, resulting in local privilege escalation.

http://www.courtesan.com/bugzilla/show_bug.cgi?id=157

The patch listed in the bug report above has been tested with gentoo on
x86/i686/kernel 2.6.8.1 with the latest stable glibc, etc, and appears
to work fine.

I think that someone should probably find out if there's any other
shells that export functions through the environment; I definitely
haven't had time to go through systematically and find out.

Anyways, keep me posted if you find out anything more.

Sorry above was reported by: Liam Helmer <lhelmer@strongboxlinux.com> 

This one is no herd, so grabbing devs from ChangeLog. Please provide a fixed ebuild.

i dont think this is a security bug, i think it was fixed upstream because it
could confuse users (exported functions in your current shell affecting your
sudo comands), after all, you could just make a script called ifconfig and put
it in your $PATH before /sbin/ifconfig.

The fix is obviously to use absolute paths, eg /sbin/ifconfig in your scripts.

Could we get some clarification that this _is_ a security bug?

I have a local ebuild with the existing patch already and am testing.
However the patch may be a little incomplete as it sits right now and perhaps should scrub the entire env. Hopefully Todd C Miller will provide an update here http://www.courtesan.com/bugzilla/show_bug.cgi?id=157

It's a security bug.  Look at the courtesan.com bug detail -- it explains
exactly how to exploit it.

ping me on IRC if you want to discuss it further.  happy to walk through the
exploit to explain it more.

Sorry about that tavis did not mean to yank you out of the CC: loop. 
See comment #4 from Kurt to you.

Uhh, thanks Kurt, but if this is a bug, then so is the $PATH exploit I
described above.

the patch is a convenience fix, you can stop the $PATH "exploit" by using
env_reset, but stripping all the names of commands using env_delete would be
tedious. 

I'm not convinced this is a security bug.

If you want me to demonstrate my exploit:

from sudoers:
%wheel  ALL=(ALL)   NOPASSWD: /tmp/script

/tmp/script:

#!/bin/bash
uptime
$ sudo /tmp/script 
 21:06:43 up  4:47,  3 users,  load average: 0.27, 0.13, 0.12
taviso@insomniac:~$ printf "%s\n$s" '#!/bin/bash' 'cat /etc/shadow' > uptime
taviso@insomniac:~$ chmod 755 uptime 
taviso@insomniac:~$ PATH=.:$PATH sudo /tmp/script 
root:xxxxxxxxxxxxxxx
...

sorry, just to clarify: adding env_delete ifconfig to sudoers would his exploit
working, just as adding env_reset to sudoers would stop mine.

Tavis Ormandy discussed this bug in great detail. The finial solution for
gentoo will be to add this patch for good house keeping and enable by default
env_reset to mitigate the problems with PATH and any other unknowns with env
handling.

For those wishing to work around this problem now simply adding
Defaults        env_reset
# Solves the problem at hand.
Additionaly if you find you need a group/user which needs to not have his env
flushed then you can add something like this to your conf as well.
Defaults:%wheel !env_reset

Tavis Ormandy will be patching sudo and making any conf changes.

^^^ Tavis Ormandy and myself discussed this bug in great detail.

Okay, I've committed an ebuild that sets env_reset to the default sudoers file,
this setting effectively stops this issue, although the reason it isn't defined
by default is that some scripts rely on this behaviour (being able to export
variables to the sudo session), there are comments in the file explaining how
to enable the old behaviour.

Sudo access really is for trusted users, giving sudo access to users who are
going to abuse it is tantamount to mailing them the root pass :)

I've applied the patch from the bug, although this is really just a convenience
patch, not a security patch. without env_reset there are many other ways you
could get root through the environment, IFS,PATH,etc,etc.

The ebuild is ~*, do the security team feel it needs to go live asap, or are
you okay for this to get some testing in ~x86 to see if there are any
complaints about it?

I think leaving it ~arch would be ideal for testing. If there are any scripts
that rely on this new 'old' behavior they will have atleast have a chance to
manifest themselves.
It's my understanding also that a 1.6.8p2 should be released tomorrow.

hi,
much of this reminds me of a similar thing, i discovered a few days ago...
look:
sudoers:
%wheel        ALL=(ALL)       NOPASSWD:/sbin/modprobe

in this case, an administrator allows users to use the modprobe command...
(which is a bad idea anyways, but who knows...)
now:
as user do the following:
$ sudo /sbin/modprobe -c -C /etc/shadow > test

... and you'll be very surprised...

i dont think however, that this is a security bug... (comments?)

just in case, i can a open a bug for it, if you want

best regards

florian

Arches please test and report back on failure and success for sudo-1.6.8_p1-r2.
Do NOT mark stable yet.

Solar just pointed out that this also works if you use the absolute paths.

Re comment #12 Agreed.
This appears configuration error only.

Looks Ok for sparc.

Note to those arch testing. don't forget to make sure the env_reset makes it
into your /etc/sudoers file. If you ever installed sudo before your going to
end up with the default suoders file. so etc-update and all that jazz.

On the other hand, having a restricted sudoers (no su - for instace) this
fails:

gustavoz@ayanami gustavoz $ sudo su -

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password:
Segmentation fault

Gustavo: you mean like this?: %wheel ALL=(ALL) NOPASSWD: ALL, !/bin/su

if so, perhaps this is an unrelated bug on sparc?

Re comment #13, there are a million ways to get around it, giving away sudo access to non-trusted users is asking for trouble.

Actually i have almost the same sudoers as taviso has:

Defaults        env_reset
%wheel          ALL=(ALL) NOPASSWD:/tmp/script

I've tested sudo-1.6.8_p1-r2.ebuild on alpha, amd64 and ia64.  It works fine on
all of them, including env_reset.

Issue is now fixed upstream and described here:

http://www.sudo.ws/sudo/alerts/bash_functions.html

env_reset seems to work as does sudo on ppc.

that version of sudo and env_reset seem to work on ppc64.  Markus

Tavis any ETA for a push to stable?

Solar, Tavis seems to be away. Do you have any ETA for a push to stable?

app-admin/sudo-1.6.7_p5-r2 has been marked stable on x86

Arches, please mark app-admin/sudo-1.6.7_p5-r2 stable

Stable on alpha.

stable on ppc

stable on amd64

sparc stable.

stable on ppc64

Stable on mips

Ready for a GLSA but blocked waiting for other vulnerabilities to come in

"
Candidate: CAN-2004-1051
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1051
Reference: CONFIRM:http://www.sudo.ws/sudo/alerts/bash_functions.html
Reference: BUGTRAQ:20041112 Sudo version 1.6.8p2 now available (fwd)
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110028877431192&w=2

sudo before 1.6.8p2 allows local users to execute arbitrary commands
by using "()" style environment variables to create functions that are
executed instead of any program within the bash script that do not
have full pathnames
"

Debian apparently chose not to issue an advisory on this one.

From Martin Schulze :

"I'd consider this problem a non-issue or a design glitch and it seems
that it will only be a problem if the admin isn't careful with giving
access to various users."

I think we shouldn't issue a GLSA about it as well. I would rather add a few comments to the sudoers file warning about the risks associated with sudo : use full pathnames, if using bash scripts you should env_reset, and do not give access to untrusted people / untrusted applications.

Stable on hppa.

Does everyone agree that we shouldn't send a GLSA on this one ?

About the sudo general "insecurity" and documentation need, it's taken care of in bug 71750.

agreed, koon

Warnings in sudoers sounds like a good idea.

Debian just released an advisory:

http://www.debian.org/security/2004/dsa-596

oopa, accidentally posted to wrong bug, this was meant to go here:

http://bugs.gentoo.org/show_bug.cgi?id=71750#c14

Two "NO" votes, closing without GLSA.

The warning thing will be handled on bug 71750.
Anyone that disagrees should reopen this bug.