A flaw was found in sudo in the handling of ipahostname, where ipahostname from /etc/sssd/sssd.conf was not propagated in sudo. Therefore, it leads to privilege mismanagement vulnerability in applications, where client hosts retain privileges even after retracting them.

Sudo before 1.9.13 does not escape control characters in sudoreplay output.

Sudo before 1.9.13 does not escape control characters in log messages.

Sudo before 1.9.13p2 has a double free in the per-command chroot feature.

A vulnerability was found in sudo. Exposure in how sudoedit handles user-provided environment variables leads to arbitrary file writing with privileges of the RunAs user (usually root). The prerequisite for exploitation is that the current user must be authorized by the sudoers policy to edit a file using sudoedit.

selinuxeditcopytfiles in sudoedit in Sudo before 1.9.5 allows a local unprivileged user to gain file ownership and escalate privileges by replacing a temporary file with a symlink to an arbitrary file target. This affects SELinux RBAC support in permissive mode. Machines without SELinux are not vulnerable.

The sudoedit personality of Sudo before 1.9.5 may allow a local unprivileged user to perform arbitrary directory-existence tests by winning a sudoedit.c race condition in replacing a user-controlled directory by a symlink to an arbitrary path.

DISPUTED Sudo through 1.8.29 allows local users to escalate to root if they have write access to file descriptor 3 of the sudo process. This occurs because of a race condition between determining a uid, and the setresuid and openat system calls. The attacker can write "ALL ALL=(ALL) NOPASSWD:ALL" to /proc/#####/fd/3 at a time when Sudo is prompting for a password. NOTE: This has been disputed due to the way Linux /proc works. It has been argued that writing to /proc/#####/fd/3 would only be viable if you had permission to write to /etc/sudoers. Even with write permission to /proc/#####/fd/3, it would not help you write to /etc/sudoers.

A flaw was found in the way sudo read the device number of the tty from field 7 (ttynr) from "/proc/[pid]/stat". A local attacker could use this flaw to escalate his privilege to root.

A vulnerability in functionality for adding support of SHA-2 digests along with the command was found. The sudoers plugin performs this digest verification while matching rules, and later independently calls execve() to execute the binary. This results in a race condition if the digest functionality is used as suggested (in fact, the rules are matched before the user is prompted for a password, so there is not negligible time frame to replace the binary from underneath sudo). Versions affected are since 1.8.7.

CVE assignment:

http://seclists.org/oss-sec/2015/q4/327

sudoedit in Sudo before 1.8.15 allows local users to gain privileges via a symlink attack on a file whose full path is defined using multiple wildcards in /etc/sudoers, as demonstrated by "/home///file.txt."

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

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.

Sudo VISudo 1.6.8 and earlier allows local users to corrupt arbitrary files via a symlink attack on temporary files.