desktop-packages team mailing list archive

[Mark Smith <1219337@xxxxxxxxxxxxxxxxxx>]

Tyler,
it's great that this bug will be fixed. However, I have some concerns about the mitigations factors.

1) Timestamp: Easily found in the auth.log, and easily bypassed due to
an unlocked clock.

2) TTY: The tty of the first gnome-terminal running is (as far as I can
tell) /dev/pts/0. That's predictable, so if the auth.log contains a sudo
session on /dev/pty/0, it's trivial to re-create the tty.

3) inode: Does this mean Session ID? If so, I'm worried. If not, we have
a bigger problem. Here's why:


hexdump -d /var/lib/sudo/mscs/0 
0000000   00013   00000   00000   00000   34816   00000   00000   00000
0000010   00003   00000   00000   00000   01000   00000   00005   00000
0000020   31291   00000   00000   00000                                
0000028

hexdump -d /var/lib/sudo/mscs/0 
0000000   00013   00000   00000   00000   34816   00000   00000   00000
0000010   00003   00000   00000   00000   01000   00000   00005   00000
0000020   01464   00000   00000   00000                                
0000028


See 31291, and 01464 in the second column near the bottom? It turns out that they correspond to SID.
I checked using python:

import os
pid = os.getpid()
sid = os.getsid(pid)
print pid, sid

1775 1464

I tested this several times. Since the setsid can generate a new sid,
and there are only 32768 possible SIDs as configured out of the box, how
hard would it be to brute force the sid, simply running sudo -n -s? If
SID isn't == to Inode, where's inode in that file? The ls -i command
reports no difference in the inode of the file itself (545179 both
times, even if the gnome-terminal is closed and re-opened.)

I've poked at the sid option already, and have indeed had good success
with getting sessions matching the sid using this brute force method.
It's now a question of how I get that session lined up with the pty
(which is predictable) and see if sudo -s works without a password at
the last escalation time. Perhaps there is some other security feature
that will block me, but right now I don't see it.

Thoughts?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-desktop-privileges in Ubuntu.
https://bugs.launchpad.net/bugs/1219337

Title:
  Users can change the clock without authenticating, allowing them to
  locally exploit sudo.

Status in GNOME Control Center:
  Unknown
Status in sudo:
  Unknown
Status in Unity:
  Invalid
Status in policykit-desktop-privileges package in Ubuntu:
  Opinion
Status in sudo package in Ubuntu:
  Triaged
Status in policykit-desktop-privileges source package in Precise:
  Opinion
Status in sudo source package in Precise:
  Triaged
Status in policykit-desktop-privileges source package in Trusty:
  Opinion
Status in sudo source package in Trusty:
  Triaged
Status in policykit-desktop-privileges source package in Utopic:
  Opinion
Status in sudo source package in Utopic:
  Triaged
Status in policykit-desktop-privileges source package in Vivid:
  Opinion
Status in sudo source package in Vivid:
  Triaged

Bug description:
  Under unity and cinnamon, it is possible for a user to turn off
  network-syncronized time and then change the time on the system. It is
  also possible to "cat /var/log/auth.log" and find the last time a user
  authenticated with sudo, along with which pty they used. If a user had
  used a terminal and successfully authenticated with sudo anytime in
  the past, and left the sudo file in "/var/lib/sudo/<username>/", a
  malicious user could walk up to an unlocked, logged in machine and
  gain sudo without knowing the password for the computer.

  To do this, a user would only need to launch a few terminals, figure
  out which pty they were on via "tty", find the an instance in
  /var/log/auth.log where sudo was used on that PTY, and set the clock
  to that time. Once this is done, they can run (for example) "sudo -s"
  and have a full access terminal.

  1) This has been observed on Ubuntu 13.04, and may work on other versions.
  2) This may have an effect on various window managers, but I confirmed it on Unity and Cinnamon
  3) I expected to have to authenticate when I changed the time and date, as I do on Gnome and KDE. I also expected to be denied permission to auth.log
  4) I was able to change the system time to whatever I wanted, and view auth.log. This was sufficient to access sudo without having to type my password.

  Note: This bug also affects any version of OS X, though the mechanism
  is different. Some versions don't require you to authenticate to
  change the time through the GUI, but some do. No version I've seen
  requires authentication to use the "systemsetup" command, which can
  alter the time from the command line. This may be an overall bug in
  sudo. Why can I bypass security by changing the time?!

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/1219337/+subscriptions