Comment 35 for bug 1219337

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?