Sudo's secure path option can be circumvented

Sudo “secure path” feature works by replacing the PATH environment variable with a value specified in the sudoers file, or at compile time if the –with-secure-path configure option is used. The flaw is that sudo only replaces the first instance of PATH in the environment. If the program being run through sudo uses the last instance of PATH in the environment, an attacker may be able to avoid the “secure path” restrictions.

Sudo 1.3.1 through 1.6.9p22 and Sudo 1.7.0 through 1.7.2p6.

This vulnerability has been assigned CVE-2010-1646 in the Common Vulnerabilities and Exposures database.

Most versions of the C library function getenv() return the first instance of an environment variable to the caller. However, some programs, notably the GNU Bourne Again SHell (bash), do their own environment parsing and may choose the last instance of a variable rather than the first one.

An attacker may manipulate the environment of the process that executes Sudo such that a second PATH variable is present. When Sudo runs a bash script, it is this second PATH variable that is used by bash, regardless of whether or not Sudo has overwritten the first instance of PATH. This may allow an attacker to subvert the program being run under Sudo and execute commands he/she would not otherwise be allowed to run.

Exploitation of the bug requires that Sudo be configured with the “secure path” option enabled, either at build-time (via configure) or at run-time (via sudoers). It also requires that the user be granted permission to run a command that does its own environment handling, such as a bash script, and that this command does not set PATH itself. If the “secure path” feature is not in use there is no impact.

The bug is fixed in sudo 1.6.9p23 and sudo 1.7.2p7.

Evan Broder and Anders Kaseorg of Ksplice, Inc.