Anders Kaseorg and Evan Broder reported a flaw in the way sudo handled duplicated environment variables. When sudo set certain environment variables (such as PATH set to securepath value, or special sudo environment variables SUDO), the value overwrote first value from user's environment (if it had been preserved and had not removed previously due to envreset / envkeep / envdelete settings), but left following environment variables with the same name unchanged.

This problem can be used to override securepath setting from /etc/sudoers file for shell scripts executed using sudo, as bash uses last PATH environment variable value. In configurations where securepath is used to enforce sane PATH setting for shell scripts, this can allow users with the privileges to run some script using sudo to run arbitrary command with the privileges of the target user.

Upstream fixes to handle duplicated environment variables: http://www.sudo.ws/repos/sudo/rev/3057fde43cf0 http://www.sudo.ws/repos/sudo/rev/a09c6812eaec

This issue affects sudo packages shipped in Red Hat Enterprise Linux 5, however not the default configuration. In default configuration, no securepath is set. envreset is used by default, and PATH is not preserved during the environment reset (unlike the upstream sudo default).

The sudo packages in Red Hat Enterprise Linux 3 and 4 do not allow setting securepath in the /etc/sudoers, there is no compile-time default for the securepath either. Whether the user PATH setting is preserved depends on envreset / envdelete configuration.

Current Fedora configuration specifies securepath, but also removes PATH from the environment by default.

sudo 1.6.x before 1.6.9p21, when the runasdefault option is used, does not properly set group memberships, which allows local users to gain privileges via a sudo command.

The command matching functionality in sudo 1.6.8 through 1.7.2p5 does not properly handle when a file in the current working directory has the same name as a pseudo-command in the sudoers file and the PATH contains an entry for ".", which allows local users to execute arbitrary commands via a Trojan horse executable, as demonstrated using sudoedit, a different vulnerability than CVE-2010-0426.

Florian Weimer of Red Hat reports:

the sudoers manual page says this:

EXEC and NOEXEC

If sudo has been compiled with noexec support and the underly‐ ing operating system supports it, the NOEXEC tag can be used to prevent a dynamically-linked executable from running further commands itself.

In the following example, user aaron may run /usr/bin/more and /usr/bin/vi but shell escapes will be disabled.

aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

And:

To enable noexec for a command, use the NOEXEC tag as documented in the User Specification section above. Here is that example again:

aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

This allows user aaron to run /usr/bin/more and /usr/bin/vi with noexec enabled. This will prevent those two commands from executing other commands (such as a shell). If you are unsure whether or not your system is capable of supporting noexec you can always just try it out and check whether shell escapes work when noexec is enabled.

However, the filtering DSO does not intercept all glibc functions which allow to spawn a shell. At least popen, system, and wordexp are missing:

Show quoted text 0000000000000c80 T execl 0000000000000cc0 T execl 0000000000000d00 T execl 0000000000000d40 T execle 0000000000000d80 T execle 0000000000000dc0 T execle 0000000000000e00 T execlp 0000000000000e40 T execlp 0000000000000e80 T execlp 0000000000000ec0 T exect 0000000000000f00 T exect 0000000000000f40 T exect 0000000000000f80 T execv 0000000000000fc0 T execv 0000000000001000 T execv 00000000000011c0 T execve 0000000000001200 T execve 0000000000001240 T execve 0000000000001040 T execvp 0000000000001080 T execvp 00000000000010c0 T execvp 0000000000001100 T execvP 0000000000001140 T execvP 0000000000001180 T execvP 0000000000001280 T execvpe 00000000000012c0 T execvpe 0000000000001300 T execvpe 0000000000001340 T fexecve 0000000000001380 T fexecve 00000000000013c0 T fexecve 0000000000001480 T posixspawn 0000000000001440 T posixspawn 0000000000001400 T posixspawn 0000000000001540 T posixspawnp 0000000000001500 T posixspawnp 00000000000014c0 T posixspawnp

The source file src/sudonoexec.c contains this comment:

/ Dummy versions of the execve() family of syscalls. We don't need to stub out all of them, just the ones that correspond to actual system calls (which varies by OS). Note that it is still possible to access the real syscalls via the syscall() interface but very few programs actually do that. /

This is wrong. Interposing execve does not override internal calls to execve within glibc.

The right fix is to set a seccomp filter which blocks execve in the DSO (after enabling PRSETNONEWPRIVS), rather than attempting to play catch-up with glibc.

sudoedit (aka sudo -e) in sudo 1.6.8 opens a temporary file with root privileges, which allows local users to read arbitrary files via a symlink attack on the temporary file before quitting sudoedit.

sudo before 1.6.8p2 allows local users to execute arbitrary commands by using "()" style environment variables to create functions that have the same name as any program within the bash script that is called without using the program's full pathname.

Sudo before 1.6.8 p12, when the Perl taint flag is off, does not clear the (1) PERLLIB, (2) PERL5LIB, and (3) PERL5OPT environment variables, which allows limited local users to cause a Perl script to include and execute arbitrary library files that have the same name as library files that are included by the script.

Incomplete blacklist vulnerability in sudo 1.6.8 and earlier allows local users to gain privileges via the (1) SHELLOPTS and (2) PS4 environment variables before executing a bash script on behalf of another user, which are not cleared even though other variables are.

Race condition in sudo 1.3.1 up to 1.6.8p8, when the ALL pseudo-command is used after a user entry in the sudoers file, allows local users to gain privileges via a symlink attack.

sudo 1.6.8 and other versions does not clear the PYTHONINSPECT environment variable, which allows limited local users to gain privileges via a Python script, a variant of CVE-2005-4158.

Multiple race conditions in the (1) Sudo monitor mode and (2) Sysjail policies in Systrace on NetBSD and OpenBSD allow local users to defeat system call interposition, and consequently bypass access control policy and auditing.