DISPUTED In Sudo through 1.8.29, the fact that a user has been blocked (e.g., by using the ! character in the shadow file instead of a password hash) is not considered, allowing an attacker (who has access to a Runas ALL sudoer account) to impersonate any blocked user. NOTE: The software maintainer believes that this CVE is not valid. Disabling local password authentication for a user is not the same as disabling all access to that user--the user may still be able to login via other means (ssh key, kerberos, etc). Both the Linux shadow(5) and passwd(1) manuals are clear on this. Indeed it is a valid use case to have local accounts that are only accessible via sudo and that cannot be logged into with a password. Sudo 1.8.30 added an optional setting to check the shell of the target user (not the encrypted password!) against the contents of /etc/shells but that is not the same thing as preventing access to users with an invalid password hash.

DISPUTED In Sudo through 1.8.29, an attacker with access to a Runas ALL sudoer account can impersonate a nonexistent user by invoking sudo with a numeric uid that is not associated with any user. NOTE: The software maintainer believes that this is not a vulnerability because running a command via sudo as a user not present in the local password database is an intentional feature. Because this behavior surprised some users, sudo 1.8.30 introduced an option to enable/disable this behavior with the default being disabled. However, this does not change the fact that sudo was behaving as intended, and as documented, in earlier versions.

Sudo failed to properly reset group permissions, when "runasdefault" option was used. If a local, unprivileged user was authorized by sudoers file to perform their sudo commands under default user account, it could lead to privilege escalation.

Upstream bug report: http://www.gratisoft.us/bugzilla/showbug.cgi?id=349

Upstream patch: http://www.gratisoft.us/bugzilla/attachment.cgi?id=255

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read. This can be triggered by arbitrary local users with access to Sudo by entering a password of seven characters or fewer. The impact could vary depending on the compiler and processor architecture.

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

Due to upstream changes in how sudo 1.7.3 handles group membership checks, the patch used to correct bug #235915 (sudo can't always correctly determine group memberships) was incorrectly rediffed, making sudo in Fedora once again vulnerable to CVE-2009-0034 (incorrect handling of groups in RunasUser).

Statement:

Not vulnerable. This issue did not affect the versions of sudo as shipped with Red Hat Enterprise Linux 4, 5, or 6.