Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Feb 2013 11:23:36 -0500
From: "Todd C. Miller" <>
To: oss security list <>
Subject: CVE request: potential bypass of sudo tty_tickets constraints

Sudo 1.8.6p7 and 1.7.10p6 are now available which include a fix for
the following bug:

Potential bypass of sudo tty_tickets constraints

    When a user successfully authenticates with sudo, a time stamp
    file is updated to allow that user to continue running sudo
    without requiring a password for a preset time period (five
    minutes by default).

    This time stamp file can either be common to all of a user's
    terminals, or it can be specific to the particular terminal the
    user authenticated themselves on.  The terminal-specific time
    stamp file behavior can be controlled using the "tty_tickets"
    option in the sudoers file.  This option has been enabled by
    default since sudo 1.7.4.  Prior to sudo 1.7.4, the default was
    to use a single time stamp for all the user's sessions.

    A vulnerability exists because the user can control which
    terminal the standard input, output and error file descriptors
    (0-2) refer to.  A malicious user could use this to run commands
    via sudo without authenticating, so long as there exists a
    terminal the user has access to where a sudo command was
    successfully run by that same user within the password timeout
    period (usually five minutes).

    The vulnerability does not permit a user to run commands other
    than those allowed by the sudoers policy.

Sudo versions affected:
    Sudo 1.3.5 through 1.7.10p6 and sudo 1.8.0 through 1.8.6p7 when
    the "tty_tickets" option is enabled.  This option is enabled
    by default in sudo 1.7.4 and above.

    The vulnerability can be triggered when the standard input,
    output and error file descriptors (0-2) of a process are closed
    and a different terminal device is opened and connected to those
    descriptors.  When sudo tries to determine the terminal device
    via the ttyname() function, it will get the name of the other
    terminal instead.  The core problem is that while ttyname() can
    be used to determine the name of the terminal device connected
    to a specific file descriptor, there is no portable way to
    determine the name of the terminal associated with the session
    the process belongs to.  However, on many systems it is possible
    to determine this by using the /proc file system or the sysctl()

    Most operating systems that have the /proc file system provide
    a way to determine the controlling terminal device number for
    a process; this information is used by the ps command for
    example.  On Linux, this is the tty_nr field in /proc/self/stat
    (the seventh entry).  On systems with an SVR4-style /proc, this
    is the pr_ttydev member of struct psinfo, which comes from
    /proc/self/psinfo.  Most BSD systems that support the sysctl()
    function also provide a way to get the terminal device number
    via the KERN_PROC_PID sysctl.  By mapping this device number
    to a file name, it is possible to get the name of the terminal
    file without resorting to ttyname().  Sudo began using this
    method to determine the process's terminal starting with version
    1.8.5 and 1.7.10.

    However, sudo still used the ttyname() function as a fall back
    when no controlling terminal was found via /proc or sysctl().
    This allowed a malicious process to cause sudo to use ttyname()
    simply by creating a new session without a controlling tty
    before executing sudo.  In sudo 1.8.6p6 and 1.7.10p5, this fall
    back behavior was removed.  This fixed the vulnerability for
    systems where the process's controlling terminal could be
    determined via /proc or sysctl().

    Sudo 1.8.6p7 and 1.7.10p6 contain an additional fix for systems
    without /proc or sysctl() that stores the POSIX session ID in
    the time stamp file itself.  The controlling terminal is specific
    to the POSIX session it is associated with.  It is not possible
    for two processes in different sessions to have the same
    controlling terminal.  Sudo will now compare the current session
    ID with the one in the time stamp file and ignore the time stamp
    file if the session ID does not match.  This has the additional
    benefit of making it much less likely that a user will be able
    to reuse the time stamp file after logging out and back in again
    on the same terminal.

    A (potentially malicious) program run by a user with sudo access
    may be able to bypass the "tty_ticket" constraints.  In order
    for this to succeed there must exist on the machine a terminal
    device that the user has previously authenticated themselves
    on via sudo within the last time stamp timeout (5 minutes by

    This program may use sudo's -n flag to "probe" the terminals
    in question to see if there is an active time stamp file for
    the user.  Prior to sudo 1.8.6 and 1.7.10, if a password was
    required when the -n flag was specified the failure would not
    be logged, allowing the program to perform such probes without
    being detected.  The successful command (if any), would still
    be logged.

    The bug is fixed in sudo 1.8.6p7 and 1.7.10p6.

    Ryan Castellucci brought the initial ttyname() issue to my
    attention.  Subsequently, James Ogden discovered that using
    setsid() to create a new session would cause sudo to fall back
    to using ttyname().

    Other shortcomings in sudo's "tty_tickets" functionality have
    been known and discussed openly for some time.  There is a long
    discussion about them at:

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.