This is quite a common way to bypass sudo (get access to a user who already logged in as sudo and reset clock), I remember seeing the same exploit (or variations) time and time again, for multiple systems.
I'm very surprised that the 'sudo' timeout feature wasn't implemented against the system's RTC using something like CLOCK_MONOTONIC. Or put differently, the idea that you'd use absolute time to implement a requirement that's defined in terms of relative time seems a bit absurd. Anyone have any clues as to why this wasn't implemented that way?
For reference, CLOCK_MONOTONIC is defined in time.h and is part of the POSIX standard.
From the 2004 version of 1003.1:
CLOCK_MONOTONIC
The identifier for the system-wide monotonic clock, which is defined
as a clock whose value cannot be set via clock_settime() and which
cannot have backward clock jumps. The maximum possible clock jump
shall be implementation-defined.
Edit: This is also an excellent example of why "nullability" is a really, really important concept. If the choice was to delete the timestamp file rather than set it to a magic number which is also an allowed value, this issue could be avoided by simply treating "missing timestamp file" as a timestamp value of -inf.
Edit 2: Just doing a bit more reading on this... on many platforms CLOCK_MONOTONIC resets on reboot, so that's no bueno unless combined with a surefire reboot detection method (if you know of one, go answer my StackOverflow question here [1]). You'll also want to fail the check if the time value read is less than the one stored (indicates overflow or other tampering, and overflows should be far enough apart that this will never happen). It's also subject to NTP time slewing [2] which could be another attack vector. Some systems have support for a CLOCK_MONOTONIC_RAW which is not subject to slewing, however I don't believe this is part of the POSIX standard, and if you were to use this there's a decent chance it wouldn't be very accurate on systems with cheap/noisy/otherwise-inaccurate RTCs.
CLOCK_MONOTONIC is not available on OS X. Also, isn't CLOCK_MONOTONIC_RAW fetching the counter from rdtsc instruction on x86? (And therefore can go backwards in time if your process is migrated to another CPU).
Keep in mind, also, that the CLOCK_MONOTONIC is not part of the core POSIX standard, so OS X is technically "compliant" even though they didn't implement it. Add this to a list of annoyances, such as no pthread_cond_timed_wait().
You can, however, get a monotonic clock by getting access to the clock service on mach.
Not sure if processor affinity would affect that code (don't have time right now to do the in depth reading on it), but you could always set affinity to CPU0. Though then you'd have to make sure to run the sudo'd command as a child process and appropriately reset affinity to default before a call to exec...
On OS X, use mach_absolute_time() to get a monotonic clock. A lot of APIs in OS X use the monotonic clock, e.g. CoreAnimation wraps mach_absolute_time() as CACurrentMediaTime() and uses that to calculate animation start times and delays.
You need to be an administrator, but you do not need to be root. This exploit lets you start from an administrator account for which you don't have a password (but have gained access to through other means, like exploiting an app run by an administrator user) and then leverage that into root access, something that normally requires the password for the account.
You can actually prevent the exploit from working by locking the "date and time" tab of the system preferences. The exploit will then cause the usual password popup to appear. (On 10.6 at least.)
If you don't trust the binaries, I found it easy to update the vulnerable sudo v1.7.0 on my OS X 10.6 machine by building from source and overwriting the one supplied by Apple:
0) Backup /usr/bin/sudo (temporarily; you'll want to delete the old sudo after verifying the new one works), and backup /etc/sudoers just to be safe
1) Download the source for sudo v1.7.10p7 linked on sudo's homepage: http://www.sudo.ws
2) Untar, ungzip, go to resulting source directory
3) Run configure, telling it to overwrite the vulnerable sudo
If you use `configure --prefix=/usr/bin`, you'll end up with sudo installed in /usr/bin/bin/sudo. Instead, try
./configure --prefix=/usr
to use the /usr hierarchy (/usr/bin, /usr/sbin, /usr/share, etc...) instead of the /usr/local hierarchy.
Also, if you're able to run an executable in the current directory without specifying its location, as in configure instead of ./configure, then you have . (pwd) in your $PATH, which isn't recommended because a malicious executable might be in the directory you're in, and it might be named something like ls. Just listing the directory could have you owned.
The user has to be an admin and have executed sudo previously for this to work. I hope that anybody who's smart enough to have access to this command (and admin membership) is equally qualified to parse scripts that may exploit this vulnerability...
Not at all a safe assumption. Most importantly, it's not that uncommon for even less experienced Mac users to copy and paste Terminal commands to solve one problem or another. A lot of those "Just type this!" solutions I've seen involve sudo somewhere.
But on top of that, maybe I don't understand your meaning here, but do you do a security audit on every line of every script that you ever run? Especially scripts that you run without sudo? I know that I don't.
Not even that. Lots of Mac help sites will include snippets of Bash code for the user to enter (say, something using rm to delete files the Finder is having trouble statting), and people will just enter those. You don't even need to do anything sneaky with the copy/paste process. Just offer some malicious code and expect the user to run it blindly since they wouldn't be coming to MacNoobHelp.com if they were capable of vetting for exploits.
- The default user created at setup of OSX is in the admin group.
- Certainly the 'has run sudo' is a bit of a restriction, but even running something like the Homebrew install script runs sudo. (Maybe 'users that run Homebrew without understanding sudo' is an even smaller restriction, but a few members of my research group live in exactly this intersection!)
- Do you habitually read every line of source code your computer would execute before you run that code?
I was unaware of being placed in the admin group by default. Is the admin group similar to the wheel group or is there also a wheel group for sudo access?
And yes, I very seldom run scripts copied from somebody else so when I do, I make sure I know what is being run. Granted, I'm a Linux and Windows user so the OSX philosophy might be different.
To be fair, I hadn't read the script in detail when I wrote my post, just far enough to see there was a definition of a sudo function. On review, it looks like they either call it to chmod/chgrp HOMEBREW_PREFIX (sometimes), or run sudo to create the directories.
See my comment above. I'm not referring to running 'sudo homebrew ...', I'm talking about the installation, which has to run sudo to change some permissions in HOMEBREW_PREFIX.
When you run sudo, a timestamp file is generated that sudo will then check on subsequent runs of the command allowing the user to continue to run privileged commands without having to type their password every time for a given amount of time (typically 5 minutes). Running `sudo -K` removes the timestamp file to force the user to re-enter their password on the next run of the command, but starting with version 1.6, `sudo -k`, which was an alias for `sudo -K` (I think), was changed to reset the timestamp file to the epoch (January 1st, 1970, 01:00).
This vulnerability allows a user that already has sudo ability to infinitely allow themselves the ability to run any command they already have privilege to run under the given system's sudo configuration without a password forever, because resetting the system clock to the epoch tricks sudo into thinking that sudo has just always been authenticated to run without a password.
This vulnerability does not allow users that already do not have any sudo privileges to obtain them, nor does it allow any users with sudo privileges the ability to run any command with sudo if they are restricted to certain commands.
This is a very old bug on UNIX-like systems. - I'm surprised it's still around on OS X (and surprised that this is news).
IIRC, it's because sudo -k checks whether the current time > time_at_which_you_entered_password + ttl[0]
By resetting this clock, you make the current time before this cutoff, therefore fooling the computer into thinking you don't need to enter a password.
[0] ie, how long it takes for your password to "expire" before requiring you to enter it again.
How much sense would it make to annotate a variable as being representative of a "present time" and then have the compiler insert a check that the variable must be greater than the time at which the file was compiled (plus or minus some fuzz to account for daylight savings and time zones)?
It would be a bandaid that could be circumvented by the same exploit using not 1970-01-01 but the date of latest OS/binary update release - that date would be >= compilation date, and <= today, so would work.
Does anyone else here us EE mobile? When I try to access this story it says it's 'only suitable for over 18s'. Is there something dodgy in the comments?
You'd need interactive signatures to prevent replays of very old timestamps, which significantly hurts scalability of the signed timestamps. However, I suppose with a weaker trust model one could have a federated signed timestamp service, where you could get timestamps over TLS/SSL.
