Fellow Naked Security writer Graham Cluley recently pointed out an intriguing bug in the program sudo.
If you’re not a Unix-flavoured user (and I include Linux and OS X users in that category), then you may not have come across sudo before.
It’s very similar in concept to the Run As... feature in Windows. It allows you, assuming you are authorised, to run commands as someone else.
Although you can use both Run As... and sudo to reduce your privileges for safety, you’ll mostly find yourself using them to boost your power so you can perform one-off administrative tasks without actually having to login as an administrator.
You can probably see why this is a good idea.
When you login as an administrator, especially on Unix-like systems, the administrator’s almighty authority applies to everything you do.
Even if you just start NOTEPAD to edit one of your own files, you’re doing so as the superuser.
It’s even worse having unnecessary powers if you need to run more complex software, such as a browser or a word processor. Any vulnerability that gets exploited will probably be able to take over the whole system, not just one user’s part of it.
So sudo is intended to reduce, or even to remove, the need ever to login as the superuser, also known as root, on Unix systems.
And the name of sudo reflects this fact, standing as it does for “do as superuser”.
→ Strictly speaking, sudo stands for “substitute user and do,” or (to use the Unix terminology for substituting a user) “setuid and do”. The setuid() function in Unix is how you change from one user to another in order to gain or to drop privilege. In day-to-day use, though, sudo is almost always for becoming superuser for one command. Whether to pronounce it literally, as “soo-doo”, or metaphorically, as “pseudo”, is a matter of personal taste.
Many modern Unix-like systems – Linux distributions such as the Ubuntu family, for instance, and UNIX derivatives such as OS X – don’t even have the root login enabled by default. Using sudo is the only way to perform administrative tasks.
By default, sudo asks you for your password (or, if you prefer, for root‘s password) whenever you want to do something as the superuser.
If you haven’t run sudo before, it also spits out what the source code calls a lecture:
Of course, system administration rarely involves just one command at a time.
So sudo has a grace period, five minutes by default, within which it doesn’t ask for your password again:
You can probably guess where this is going.
As soon as you start adding get-out-of-jail-free components into your security software, you add the risk of introducing exploitable holes.
For example, what if you log out and log back in? Should your sudo authority survive or not?
How do you reliably keep track of elapsed time? What if another user fiddles with the system clock?
And what if a security-conscious administrator uses sudo for one or two commands and deliberately wants to revoke his authority by discarding the rest of his five-minute no-password-needed window?
The authors of sudo dealt with the last case by providing the sudo -k option, which, in the words of sudo‘s manual page, “invalidates the user’s timestamp.”
At first, this was done simply by removing the database entry used to keep track of the last time the user authenticated. (The “database entry” is handled elegantly and simply by using the filesystem’s timestamp on a protected directory called /var/db/sudo/username.)
But deleting the timestamp data completely meant that sudo couldn’t tell, when next you used it, that you’d ever run it before. So you’d get the “lecture” all over again next time.
And in turns out that the sort of system administrator who is conscientious enough to use sudo -k in the first place doesn’t like repetitious and mildly patronising advice from the operating system he’s administering.
So the authors of sudo added another get-out-of-jail-free component, namely that deauthorising yourself wouldn’t delete your timestamp entry altogether, as though you were a complete newbie.
Instead, when you run sudo -k the program simply forces your timestamp to a value that is certain (and I’m sure you can see where this is going) to be more than five minutes in the past.
However, the authors used what is known as an in-band signal.
→ We’ve written about the risk of in-band signalling before, in the context of mobile phones processing some phone numbers as special commands, not as numbers to be dialled. Whenever a specific input can have two meanings, ambiguity is bound to arise.
To invalidate your current timestamp, sudo sets it back to the beginning of the Epoch, which is literary geek-speak for the earliest timestamp possible on your operating system.
For historical reasons, a timestamp of zero comes out on Unix-like systems as the beginning of 01 January 1970, as shown in the timestamp image above.
Clearly, that is certain to be more than five minutes in the past, if your clock is correct.
But what if it isn’t? What if your system clock has been deliberately reset to zero by a miscreant? Or even accidentally, for example by a power failure?
Of all the incorrect timestamps that might arise by accident, you’d want to hazard a guess that midnight on 01 January 1970 is the most likely, for the simple reason that it is represented by the value zero.
And if ever someone or something could reset the clock, any cautious administrator who had deliberately relinquished his sudo authority by carefully running sudo -k would be hoist by his own petard.
(That sort of irony is not unusual in security circles: bugs can end up more severe for those who try to do the right thing than for those who simply “let the system choose”.)
This flaw should be a reminder that even simple-sounding security software like sudo, which is at its heart just a programmatic wrapper around Unix’s setuid() family of system calls, can go wrong.
Adding features, especially ones that tweak your enforcement of security, always carries the risk of making security worse.
This bug, I am happy to tell you, was quickly fixed.
The authors of sudo simply removed the ambiguity in interpreting the zero timestamp.
If the timestamp of your last use of sudo is the start of the Epoch, it means that you are deauthorised but have used sudo before.
It can no longer also be interpreted to mean that you actually used sudo at the stroke of midnight on New Year’s Day, 1970.
NB. The sudo versions affected by this flaw are 1.6.0 to 1.7.10p6 inclusive and 1.8.0 to 1.8.6p6 inclusive. The first versions patched against the bug are 1.7.10p7 and 1.8.6p7.
13 comments on “Anatomy of a bug – the five-minute insecurity window in the sudo command”
Any reason why they didn't take the current time subtract (grace period +1) and put that in timestamp. It should work!!
works until I change the clock…
Slight correction: the "su" in "sudo" actually stands for "substitute user". Sudo allows you to perform a command as any user on the system (if permitted in the config), although by default it uses root.
Sudo could also stand for "setuid and do", "switch user and do", and many others. (The man page just says "sudo – execute a command as another user".
Many admins I know spell it out as "superuser do", so my version is at least vernacular, if not strictly correct 🙂
it could stand for anything. so could awk grep sed and most cryptic commands. but the developers probably had a rationale for their choice. don't speculate, confirm.
Said @infosec geek speculatively 🙂
The sudo website says merely that it stands for "su do", without clarifying what intepretation "su" should have.
I'll stick with "superuser do", thanks.
(And, yes, I know what grep and sed stand for, and that awk ought more correctly to be AWK 🙂
Is there some way to protect against someone altering system time? eg if "date" (command) "is a file" like everything in a unix system is, (according to every entry level Linux manual I've ever seen) then something like inotify could be employed to prevent mayhem caused by altering time… no?
You shouldn't be able to change the time without being able to sudo to do it.
But some Unix distros aren't quite so strict – e.g. letting a netbook user adjust the date and time via some control panel app…
also some (many?) allow time updates automatically via NTP. now you're potentially vulnerable to network based attacks too, and a perfectly locked down system can be laid wide open to sudo attacks…
Not a Unix person, so perhaps you have to have SuperUser privs in order to view the timestamp, but wouldn't viewing the timestamp and then setting the clock within 5 minutes of that time accomplish the samething?
See my reply to @Cliff Jones: adjusting date and time should itself be privileged, but might not be on all systems. (Sudo can be configured, for example, to allow individual root commands without a password at all.)
"Whenever a specific input can have two meanings, ambiguity is bound to arise."
Amen to that, which leads to this question: Is there a multiplicity of meanings associated with the term "administrator"?
The reason I ask is that, if I'm interpreting your text correctly, It seems that in the early paragraphs of the article (4 and 6, specifically) you're using the term administrator as being synonymous with the superuser or root user.
I'm not sure about Linux or Unix proper, but in the "Unix-based" OS X (my system of choice for most purposes, and the one with which I'm most familiar), logging in as the root user is very different from logging in as an administrator…at least in the way Apple apparently defines "Admin", which does not have the same privileges as the root user.
Does “administrator” mean different things for different operating systems?
In Ubuntu, the grace period seems to apply to only the terminal (command window) session in which I entered sudo / gksudo (and possibly to processes launched from that session). So, the threat is quite limited; I'd have to type sudo <compromised program name> when I'd meant just <compromised program name> in the same terminal session (or have an attacker take over my session and do that for me).
Not sure about child processes that are run by a process already running as super user. My guess is that these can always run as super user, providing the parent process requests it. Perhaps the grace period has implications for a grandchild process, when the grandparent, but not the parent, process is running as super user?