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.