June 2, 2010
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 versions affected:
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
Most versions of the C library function getenv()
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
The bug is fixed in sudo 1.6.9p23 and sudo 1.7.2p7.
Evan Broder and Anders Kaseorg of Ksplice, Inc.