Re: CVE request: potential bypass of sudo tty_tickets constraints

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
>
> 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() 
> function.
>
> 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.
>
> 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: 
> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/87023

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRLkrJAAoJEBYNRVNeJnmTMZ0P/1MWqbRiIoSjVZnhY0d7D1WJ
wLEuWu0pGLXaM55m5CNZWP8tKO675JMI9wUekD7ea5GnJ1wIyX73+1S+j6wHvPOz
r2f3fcsV73rjfDAwqysY8RHn9YLoLbvZFGZXEOtE4S5zHcvrTqbiQDFKbA5wYSnD
61WCJOBj5flrvKXUZKCcNUnyI4g49KkZ+HCuCxpD0alfsz6krxH00aKzQLZwFvtN
5tYKoMY+m0ekVjV/fIkS0KcBvyp7nUa3blLlo/sI+RC9h8APwexpX78syngqCJmf
Y2mfl/ZgBp/td0OIWJuoUqwpaigPY0Xns2EQGF3NrkAdKOKxaBR83/c+Lmv1CiEm
WpniXQvBshs+ejkTxTTTAAZLZ9WlY/WHhHsxz/lYqgReU3P2eM2GoduAOFSIm7Hd
ciSRESdM+zz4jX/tF97YExf5oufAsvaCkATJs1oy9BHeVdJ0ebf4mLAAXXCeYjLI
djldhvm8rLEvSmMpTv/q1202Hg1+2M9Z6/gN0OQITbG7dpCsCfzBpokgsEVm0zS0
bLbj44F4UO6MgEo6fgUxQI4FA/FyrBAk1GzTCmamB0xMK+AChYlGHBZ6ccO2doXd
GzhugXIZS0NrH1Dof2gYYfTYbwd6TF/K0BTLZgsauBIbkWD2B/Lfckaaj/wI9IKn
X9OMaTqpq4SI2eEQySK0
=XUiR
-----END PGP SIGNATURE-----