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.
Mac OS X Sudo Password Bypass
21–30 of 53 posts
Re: Mac OS X Sudo Password Bypass
#22Why not add:
sudo -K
to .bash_logout
Re: Mac OS X Sudo Password Bypass
#23This non-bug was discussed last year.
Ha, so this is expected behavior?
Re: Mac OS X Sudo Password Bypass
#24Earlier quoted context omitted.
You mean installing Homebrew itself? Because if you're running "sudo brew install foo" you're doing it wrong.
Yes. And nope, I'm not referring to 'sudo brew install'. The main homebrew page says, 'run this ruby script'. The ruby script is available at: https://raw.github.com/mxcl/homebrew/go The script includes a sudo command. 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 HOMEBR…
Fair enough. I think everyone agrees that the "download and execute a random gist" method of installation is not great.
Re: Mac OS X Sudo Password Bypass
#25This non-bug was discussed last year.
Are you sure about "last year"? I thought the bug was assigned CVE-2013-1775 and discussed in late Feb 2013.
"Last Year", in internet time maybe. Here's the original CVE:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-17...
Re: Mac OS X Sudo Password Bypass
#26Can someone explain why resetting the clock will give sudo access without requesting a password?
Re: Mac OS X Sudo Password Bypass
#27Can someone explain why resetting the clock will give sudo access without requesting a password?
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.
Re: Mac OS X Sudo Password Bypass
#28Can someone explain why resetting the clock will give sudo access without requesting a password?
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.
Re: Mac OS X Sudo Password Bypass
#29Unable to access this url from UAE :-(
Re: Mac OS X Sudo Password Bypass
#30I'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.
1: http://stackoverflow.com/q/18539724/203705
2: http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE