The Sudo Hole

Adam Goode at ADBAS.NET has published a security alert and proof of concept code for an exploit of sudo on OS X.

The exploit is done by a process run from an account in the 'admin' group. Basically it just sits there and waits for the logged in user to do something with sudo.

The exploit can check if anything is done with sudo by referring to the system log (/var/log/system.log) - a file readable by anyone in the 'admin' group.

When it detects a change in this file, it attempts to 'piggyback' to root authentication on the sudo 'grace period' (default five minutes) without having to know or submit a password.

(The 'grace period' itself is kept out of bounds for even the 'admin' group (in /var/run/sudo) so attempting to read data there is futile.)

Adam suggests two ways to close this hole.

1. Redirect sudo logging to /var/log/secure.log which, Adam comments, not only has the correct permissions but is more suitable for such data; and

2. Restrict the use of the 'grace period' to the TTY that authenticated for it.

(Eliminating the grace period altogether is also suggested but is hardly practical.)

Adam's site has a full explanation on how to do the above.

It's easy to test this vulnerability without Adam's code.

1. Open a Terminal window.

2. Go to 'Window Settings', choose the 'Shell' tab, and note your TTY.

3. Perform a sudo call such as 'sudo ls' and if prompted submit your password.

4. Leave that first window open and now open a second Terminal window. Note that its TTY is not the same.

5. Perform the same command in this window ('sudo ls') and note you are not prompted for your password.

Adam implies that using any one of his three suggestions will close the hole, but that's not entirely true. They might close the hole to his particular exploit, but not to exploits in general.

Adam's exploit uses the log as a facility to tell him when there is a 'grace period' available, but in the greater scheme of things five minutes here or there is nothing.

An exploit doesn't need access to a log to determine when to make the jump: just try sudo - and if there's no 'grace period' to piggyback up on, go to sleep and wait a while. For attackers working on numbers, there's all the time in the world.

The sudo hole is real and can only be fixed by restricting the 'grace period' to the TTY that authenticated for it.