GitHub Blog Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Race condition in Sudo's pathname validation

A race condition in Sudo’s command pathname handling prior to Sudo version 1.6.8p9 that could allow a user with Sudo privileges to run arbitrary commands.

Sudo versions affected:

Sudo versions 1.3.1 up to and including 1.6.8p8.


This vulnerability has been assigned CVE-2005-1993 in the Common Vulnerabilities and Exposures database.


When a user runs a command via Sudo, the inode and device numbers of the command are compared to those of commands with the same basename found in the sudoers file (see the Background section for more information). When a match is found, the path to the matching command listed in the sudoers file is stored in the variable safe_cmnd, which is later used to execute the command. Because the actual path executed comes from the sudoers file and not directly from the user, Sudo should be safe from race conditions involving symbolic links. However, if a sudoers entry containing the pseudo-command ALL follows the user’s sudoers entry the contents of safe_cmnd will be overwritten with the path the user specified on the command line, making Sudo vulnerable to the aforementioned race condition.


Exploitation of the bug requires that the user be allowed to run one or more commands via Sudo and be able to create symbolic links in the filesystem. Furthermore, a sudoers entry giving another user access to the ALL pseudo-command must follow the user’s sudoers entry for the race to exist.

For example, the following sudoers file is not affected by the bug:

root		server=ALL
someuser	server=/bin/echo

Whereas this one would be:

someuser	server=/bin/echo
root		server=ALL


The bug is fixed in sudo 1.6.8p9.


The administrator can order the sudoers file such that all entries granting Sudo ALL privileges precede all other entries.


This problem was brought to my attention by Charles Morris.


The reason Sudo uses the inode for command matching is to make relative paths work and to avoid problems caused by automounters where the path to be executed is not the same as the absolute path to the command.

Another possible approach is to use the realpath() function to find the true path. Sudo does not user realpath() because that function is not present in all operating systems and is often vulnerable to race conditions where it does exist.