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.

sudo 1.6.0 through 1.7.10p6 and sudo 1.8.0 through 1.8.6p6 allows local users or physically proximate attackers to bypass intended time restrictions and retain privileges without re-authenticating by setting the system clock and sudo user timestamp to the epoch.

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

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.