Home page logo

oss-sec logo oss-sec mailing list archives

Re: CVE request: potential bypass of sudo tty_tickets constraints
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 27 Feb 2013 11:04:57 -0700

Hash: SHA1

On 02/27/2013 09:23 AM, Todd C. Miller wrote:
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

Summary: 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

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.

Details: 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

Impact: 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 default).

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.

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

Credit: 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: 

Please use CVE-2013-1776 for this issue.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.13 (GNU/Linux)


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]