Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Security)  >   Sudo Vendors:
(OpenBSD Issues Fix) Sudo Race Condition in Processing Command Pathnames Lets Local Users Execute Arbitrary Commands
SecurityTracker Alert ID:  1014249
SecurityTracker URL:
CVE Reference:   CVE-2005-1993   (Links to External Site)
Updated:  Jun 29 2005
Original Entry Date:  Jun 21 2005
Impact:   Execution of arbitrary code via local system, User access via local system
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): 1.3.1 up to and including 1.6.8p8
Description:   A vulnerability was reported in sudo. A local user can execute arbitrary commands.

In a certain configuration, a local user can exploit a race condition to execute arbitrary commands on the target system. If there is a sudoers 'ALL' entry that follows the local user's sudoers entry, then the flaw can be exploited.

The vendor credits Charles Morris with reporting this vulnerability.

Impact:   A local user can execute arbitrary commands in certain cases.
Solution:   OpenBSD has released a fix for OpenBSD-current and the 3.6 and 3.7 -stable branches. Patches for OpenBSD 3.6 and 3.7 are available at:

Vendor URL: (Links to External Site)
Cause:   Access control error, State error
Underlying OS:  UNIX (OpenBSD)
Underlying OS Comments:  3.6, 3.7

Message History:   This archive entry is a follow-up to the message listed below.
Jun 20 2005 Sudo Race Condition in Processing Command Pathnames Lets Local Users Execute Arbitrary Commands

 Source Message Contents

Subject:  security fix for sudo available

    A race condition in Sudo's command pathname handling could allow
    a user with Sudo privileges to run arbitrary commands.

    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 paragraph
    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

	root		server=ALL
	someuser	server=/bin/echo

    Whereas this one would be:

	someuser	server=/bin/echo
	root		server=ALL

    The problem has been fixed in OpenBSD-current as well as the
    3.6 and 3.7 -stable branches.  Patches for OpenBSD 3.6 and 3.7
    are also available:

    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.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC