Flaw in Runas Group password checking
Beginning with sudo version 1.7.0 it has been possible to grant
permission to run a command using a specified group via sudo’s
-g
option (run as group), if allowed by the sudoers file.
A flaw exists in sudo’s password checking logic that allows a user
to run a command with only the group changed without being prompted
for a password.
Sudo 1.7.0 through 1.7.4p4.
This vulnerability has been assigned CVE-2011-0010 in the Common Vulnerabilities and Exposures database.
It is possible to specify lists of users and groups that a command may be run as in a sudoers file entry. For example, given the following sudoers entry:
%sudo ALL = (ALL : ALL) ALL
a user in the sudo
group will be permitted to run any
command with any combination of user or group.
When sudo determines whether or not to prompt for a password, it
first checks whether the invoking user is root, the invoking user
is a member of an “exempt” group, or that the target user is the
same as the invoking user. If any of those three conditions are
true, no password is required. When the “runas group” support
was added in sudo 1.7.0, this logic was not updated to take the
target group into account. This resulted in sudo incorrectly
skipping the password check when the target user is the same as the
invoking user, but the invoking user is not a member of the target
group.
Exploitation of the flaw requires that sudo be configured with sudoers entries that contain a Runas group. Entries that do not contain a Runas group, or only contain a Runas user are not affected.
For example, the following entry is affected because it contains both a Runas user and a Runas group:
%sudo ALL = (ALL : ALL) ALL
Whereas this one only contains a Runas user and is not affected:
%wheel ALL = (ALL) ALL
Note that this flaw does not allow a user to run unauthorized commands, it only affects user authentication.
The flaw is fixed in sudo 1.7.4p5.
I would like to thank Alexander Kurtz for reporting this issue via Debian.