Exploiting the sudo password timeout.

I love sudo. Sudo allows me to do necessary system administration without having to login as root and potentially wrecking my system. I also really like that after issuing the first sudo command, I don’t have to type my password over and over, unless and until I leave my terminal window alone for 15 minutes.

Recently, I started using windows terminal as my preferred shell on Windows. It’s highly configurable and pretty awesome in general, and Open Source too!

One thing that seemed disappointing was that it’s not possible to open an elevated shell in a tab, when the application itself is not elevated. Combined with the lack of a sudo command in Windows, this made the application less useful than I’d hoped it would be. According to this (very chatty) bug report (#632), it turns out the reason this isn’t supported is because it’s theoretically possible to send keystrokes to any unelevated window from any other unelevated process. I’m not sure how big a problem this really is, but if this is a security risk in Windows, it’s probably a risk in Linux too.

I’ve created a small bash script to demonstrate the risk. It waits for a sudo process to show up, which is active when the user tries to run a command with sudo the first time and has to type their password. Then, the script waits for the process to disappear, assuming the password was correct and the command has finished (hopefully within sudo’s password timeout). Now we know that there’s probably some window that is allowed to run sudo commands without asking for a password. The script then lists all X windows with ‘terminal’ in its name, using xwininfo and grep, and sends the malicious command sudo ls to them, using xvkbd.


# Wait for sudo to start
until pids=$(pidof sudo)
        sleep 0.2

echo $pids

# Wait for the user to finish typing their password
while [[ $pids == $pids2 ]]
        sleep 1
        pids2=$(pidof sudo)

echo "Sudo finished, running malicious command..."
xwininfo -root -children | grep -i terminal | grep -v '10x10' | tr -s [:blank:] | cut -d ' ' -f 2 | xargs -I '{}' xvkbd -text 'sudo ls\r' -window '{}'

echo "Pwnage finished!"

The script itself doesn’t have to run in an elevated window, it just waits and bides its time to run an elevated command in another window. In this case the script has to be run manually and depends on several not quite common tools like xwininfo and xvkbd. The script also makes no attempt to hide or disguise itself. But as a proof of concept it’s easy to see how code could be written with the same functionality that is run more covertly.


I’m not sure what the best way to mitigate this problem is. Configuring sudo to ask for a password every time is possible, but that would be very user unfriendly. People would probably turn to sudo -i or su a lot more, making the problem only worse. Maybe it’s possible to disable receiving keystrokes (with the XTEST protocol) during the time sudoing without password is allowed.

Reboot to Windows from Linux

I, like many others, have a dual-boot system. I run Debian (unstable / sid) as my primary OS, and Windows 7 when I play games. Hopefully Steam coming to Linux means that I won’t have to reboot anymore, but for the moment I do.

Of course, it’s not really hard to reboot your system and then choose the correct option in th GRUB menu, but it does mean you have to stay around to prevent GRUB from booting the default OS, instead of walking to the kitchen to get a cup of coffee / tea  / [insert beverage of choice here]. Well, there’s a solution for that, a command called grub-reboot. For example:

sudo grub-reboot 6

This will set the 7th entry in the list of OSes as the default for one boot (it’s a 0-based index). Then reboot, et voila! You still have to know which entry to boot, of course, but you can just count it once and remember. Right? Well, it’s not always that simple.

The problem is that sometimes a new Linux kernel is installed and the old one is kept, to be able to reboot safely when the new kernel doesn’t work (which has actually never happened to me, but is a possibility when running Debian unstable). In that case, you might need to reboot to a different entry. Besides that, I wanted to have a nice icon to click on, that would set the grub entry and reboot me in one simple step.

I’ve created a simple shell script that reads the correct menu entry from grub.cfg and sets that up for the next boot. After that the script calls gnome-session-quit to request a reboot (you can choose between Cancel, Restart or Power Off):


# Find the menuentry containing Windows
#entry=`grep menuentry /boot/grub/grub.cfg | grep -n Windows | cut -d":" -f 1`
#entry=`grep -E '^menuentry|submenu' /boot/grub/grub.cfg | grep -n Windows | cut -d":" -f 1`
entry=`grep -E '^menuentry' /boot/grub/grub.cfg | grep -n Windows | cut -d":" -f 1`

/usr/sbin/grub-reboot $(($entry - 1))
# Use line below for gnome
#gnome-session-quit --power-off

# Use line below for xfce
xfce4-session-logout --fast

Update (16-5-2013): The version of Grub I currently use, adds support for submenus. Only top-level menuitems and submenus should be counted.

Update (12-2-2014): The current version of Grub does not count submenu items as bootable items. Changed reboot command to match XFCE, which is my current DE (a script could/should be made to auto-detect this).

Save it as ~/bin/reboot-to-windows.sh (or some such). Use chmod to make it executable. Also, you will probably have to fiddle with write rights to /boot/grub/grubenv. Either create a grub-reboot group that you add all allowed users to, and set that as the group for the file. Or you can add yourself and other allowed users to the ‘root’ group (Beware: This might introduce serious security issues). Or you can just make the file world-writeable (which allows all users to fuck up your system by corrupting the file).

Now, to create an entry in the Gnome-shell menu (yes, I use Gnome-shell), create a file ~/.local/share/applications/RebootWindows.desktop with the following contents:

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=Reboot to Windows

Where ‘your-username’ is your username, obviously. I’m not sure ~/bin/reboot-to-windows.sh will work, instead of a full path. The Icon entry refers to a svg graphic I created, here it is:
Windows reboot desktop icon
Save the file. The entry should now show up and be clickable.


Update (31-12-2012): I forgot a modification in /etc/default/grub:

# Enable grub-reboot

Otherwise, grub will just boot the first entry, no matter what.