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 versions affected:
Sudo 1.7.0 through 1.7.4p4.
This vulnerability has been assigned CVE 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.
Seen the release notes, bumping in a moment.
In tree now.
(In reply to comment #2)
> In tree now.
Great, thank you. Are we ok to call for stabilization now?
(In reply to comment #3)
> Great, thank you. Are we ok to call for stabilization now?
Thanks for the go-ahead via IRC.
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
This is a nasty security issue. amd64 done
Tested on SPARC, sudo works as usual, no problems found. Please stabilise.
I tested it on x86, looks good over here.
Stable for HPPA.
x86 stable, thanks Andreas
Thanks, folks. GLSA request filed.
check.c in sudo 1.7.x before 1.7.4p5, when a Runas group is configured, does
not require a password for command execution that involves a gid change but
no uid change, which allows local users to bypass an intended authentication
requirement via the -g option to a sudo command.
This issue was resolved and addressed in
GLSA 201203-06 at http://security.gentoo.org/glsa/glsa-201203-06.xml
by GLSA coordinator Sean Amoss (ackle).