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.
Sudo 1.6.9 before 1.8.5, when envreset is disabled, does not properly check environment variables for the envdelete restriction, which allows local users with sudo permissions to bypass intended command restrictions via a crafted environment variable.
A certain Red Hat script for sudo 1.7.2 on Red Hat Enterprise Linux (RHEL) 5 allows local users to overwrite arbitrary files via a symlink attack on the /var/tmp/nsswitch.conf.bak temporary file.
A security flaw was found in the way Sudo performed matching for user described by a password against the list of members, allowed to run particular sudo command, when the group option was specified on the command line. If a local, unprivileged user was authorized by sudoers file to run their sudo commands with permissions of a particular group (different to their own), it could lead to privilege escalation (execution of that sudo command with permissions of privileged user account (root)).
Acknowledgements:
Red Hat would like to thank Markus Wuethrich of Swiss Post - PostFinance for reporting this issue.
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.
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.
sudo 1.6.x before 1.6.9p21 and 1.7.x before 1.7.2p4, when a pseudo-command is enabled, permits a match between the name of the pseudo-command and the name of an executable file in an arbitrary directory, which allows local users to gain privileges via a crafted executable file, as demonstrated by a file named sudoedit in a user's home directory.
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.
It was discovered that sudo's sudoers file parses does not correctly handle group specification in RunasUser. If group was specified in the list (using syntax %group, to allow some user to run commands as any member of the group) and the user was already member of the group, sudo actually allowed the user to run commands as arbitrary system user.
SuSE and upstream bug report: https://bugzilla.novell.com/showbug.cgi?id=468923 http://www.gratisoft.us/bugzilla/showbug.cgi?id=327
This issue was confirmed on multiple 1.6.9 sudo versions. Latest upstream 1.7.0 was reported not to be affected, 1.6.8p12 previously shipped with Red Hat Enterprise Linux 5 was not affected as well. Problem was confirmed on 1.6.9p17 in RHEL5 and Fedora 10.
Upstream patch:
Index: parse.c =================================================================== RCS file: /home/cvs/courtesan/sudo/parse.c,v retrieving revision 1.160.2.21 diff -u -r1.160.2.21 parse.c --- parse.c 2 Nov 2008 14:35:53 -0000 1.160.2.21 +++ parse.c 23 Jan 2009 19:16:55 -0000 @@ -651,9 +651,11 @@ / If the user has a supplementary group vector, check it first. / - for (i = 0; i < userngroups; i++) { - if (grp->grgid == usergroups[i]) - return(TRUE); + if (strcmp(user, username) == 0) { + for (i = 0; i < userngroups; i++) { + if (grp->grgid == usergroups[i]) + return(TRUE); + } } if (grp->grmem != NULL) { for (cur = grp->grmem; cur; cur++) {
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.
sudo, when linked with MIT Kerberos 5 (krb5), does not properly check whether a user can currently authenticate to Kerberos, which allows local users to gain privileges, in a manner unintended by the sudo security model, via certain KRB5 environment variable settings. NOTE: another researcher disputes this vulnerability, stating that the attacker must be "a user, who can already log into your system, and can already use sudo."
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.
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.
DISPUTED Sudo 1.6.8p7 on SuSE Linux 9.3, and possibly other Linux distributions, allows local users to gain privileges by using sudo to call su, then entering a blank password and hitting CTRL-C. NOTE: SuSE and multiple third-party researchers have not been able to replicate this issue, stating "Sudo catches SIGINT and returns an empty string for the password so I don't see how this could happen unless the user's actual password was empty."
Sudo VISudo 1.6.8 and earlier allows local users to corrupt arbitrary files via a symlink attack on temporary files.
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.
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 1.6.0 through 1.6.3p7 does not properly clear the environment before calling the mail program, which could allow local users to gain root privileges by modifying environment variables and changing how the mail program is invoked.
Sudo 1.5 in Debian Linux 2.1 and Red Hat 6.0 allows local users to determine the existence of arbitrary files by attempting to execute the target filename as a program, which generates a different error message when the file does not exist.
sudo 1.5.x allows local users to execute arbitrary commands via a .. (dot dot) attack.