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.

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++) {

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.

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.

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.

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.

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 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.

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.

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."

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.

A Debian bug report [1] indicated that sudo would not ask for a user's password on GID changes, when it should be asking on both UID and GID changes. Normally, sudo does not allow users to change the GID only, but this can be changed by modifying /etc/sudoers to a non-default configuration, such as:

%group ALL=(ALL:ALL) ALL

rather than the more traditional:

%group ALL=(ALL) ALL

If you change the UID with sudo, you are asked for the user's password (unless NOPASSWD is specified), but this is not the case for GID changing:

$ sudo -l [sudo] password for vdanen: Matching Defaults entries for vdanen on this host: requiretty, alwayssethome, envreset, envkeep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LSCOLORS", envkeep+="MAIL PS1 PS2 QTDIR USERNAME LANG LCADDRESS LCCTYPE", envkeep+="LCCOLLATE LCIDENTIFICATION LCMEASUREMENT LCMESSAGES", envkeep+="LCMONETARY LCNAME LCNUMERIC LCPAPER LCTELEPHONE", envkeep+="LCTIME LCALL LANGUAGE LINGUAS XKBCHARSET XAUTHORITY", securepath=/sbin\:/bin\:/usr/sbin\:/usr/bin

User vdanen may run the following commands on this host: (ALL : ALL) ALL $ sudo -g mygroup id uid=1001(vdanen) gid=504(mygroup) groups=1001(vdanen),504(mygroup) $ sudo -k $ sudo -g sudo id uid=1001(vdanen) gid=504(mygroup) groups=1001(vdanen),504(mygroup) $ sudo -k $ sudo -u root id [sudo] password for vdanen: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

Upstream has corrected this issue upstream [2],[3].

Note that the "ALL:ALL" specification is not valid syntax for sudo 1.6.7p5 as shipped with Red Hat Enterprise Linux 4.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609641 [2] http://www.sudo.ws/repos/sudo/rev/fe8a94f96542 [3] http://www.sudo.ws/repos/sudo/rev/07d1b0ce530e

A certain Fedora patch for parse.c in sudo before 1.7.4p5-1.fc14 on Fedora 14 does not properly interpret a system group (aka %group) in the sudoers file during authorization decisions for a user who belongs to that group, which allows local users to leverage an applicable sudoers file and gain root privileges via a sudo command. NOTE: this vulnerability exists because of a CVE-2009-0034 regression.

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 granted access for particular host, when multiple netmask values have been used in sudo's Host / HostList configuration. Such configuration allowed unprivileged users, who were authorized by the sudoers file to run their sudo commands, to run these commands from any host regardless of the HostList configuration (even from hosts, which were intended according to the HostList netmask configuration not to allow execution of such commands according to the netmask).

Format string vulnerability in the sudodebug function in Sudo 1.8.0 through 1.8.3p1 allows local users to execute arbitrary code via format string sequences in the program name for sudo.

sudo 1.3.5 through 1.7.10p5 and 1.8.0 through 1.8.6p6, when running on systems without /proc or the sysctl function with the ttytickets option enabled, does not properly validate the controlling terminal device, which allows local users with sudo permissions to hijack the authorization of another terminal via vectors related to connecting to the standard input, output, and error file descriptors of another terminal. NOTE: this is one of three closely-related vulnerabilities that were originally assigned CVE-2013-1776, but they have been SPLIT because of different affected versions.

sudo before 1.7.10p5 and 1.8.x before 1.8.6p6, when the ttytickets option is enabled, does not properly validate the controlling terminal device, which allows local users with sudo permissions to hijack the authorization of another terminal via vectors related to a session without a controlling terminal device and connecting to the standard input, output, and error file descriptors of another terminal. NOTE: this is one of three closely-related vulnerabilities that were originally assigned CVE-2013-1776, but they have been SPLIT because of different affected versions.

From the upstream advisory:

When a user successfully authenticates with sudo, a time stamp file is updated to allow that user to continue running sudo without requiring a password for a preset time period (five minutes by default). This time stamp file can either be common to all of a user's terminals, or it can be specific to the particular terminal the user authenticated themselves on. The terminal-specific time stamp file behavior can be controlled using the "ttytickets" option in the sudoers file. This option has been enabled by default since sudo 1.7.4. Prior to sudo 1.7.4, the default was to use a single time stamp for all the user's sessions.

A vulnerability exists because the user can control which terminal the standard input, output and error file descriptors (0-2) refer to. A malicious user could use this to run commands via sudo without authenticating, so long as there exists a terminal the user has access to where a sudo command was successfully run by that same user within the password timeout period (usually five minutes).

The vulnerability does not permit a user to run commands other than those allowed by the sudoers policy.

This affects versions 1.3.5 through up to the fixed 1.7.10p6 version, and sudo 1.8.0 through to the fixed 1.8.7p7.

The fix for 1.7.x: http://www.sudo.ws/repos/sudo/rev/0c0283d1fafa

The fix for 1.8.x: http://www.sudo.ws/repos/sudo/rev/049a12a5cc14

External References:

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