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.
