[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 27 Feb 2013 11:04:57 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: "Todd C. Miller" <Todd.Miller@...rtesan.com>
Subject: Re: CVE request: potential bypass of sudo tty_tickets
constraints
-----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-----
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.
