For reference, CLOCK_MONOTONIC is defined in time.h and is part of the POSIX standard.
From the 2004 version of 1003.1:
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 ). 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  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.
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.
In a David Tennant voice: Wait, what?? What?!
~$ grep CLOCK_MONOTONIC /usr/include -rn
Apparently  one solution would be to #IFDEF DARWIN the following, as on Darwin SYSTEM_CLOCK is supposed to be a monotonic boot clock.
Can users reset the Mac OS X system clock without being an admin?
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
sudo make install
See also the sudo installation notes here: http://www.sudo.ws/sudo/install.html
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.
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 sure if you're alluding to this trick: http://thejh.net/misc/website-terminal-copy-paste
This particular exploit could be rather nasty when used in conjunction with the above.
curl -L http://www.example.com/some/cool/thing/install.sh | bash
- 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?
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.
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 HOMEBREW_PREFIX (sometimes), or run sudo to create the directories.
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.
IIRC, it's because sudo -k checks whether the current time > time_at_which_you_entered_password + ttl
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.
 ie, how long it takes for your password to "expire" before requiring you to enter it again.
In any case, as a security measure, preventing the clock from being set before the compile time is a bandaid for a bullet hole.
2. Because it breaks the "ttl" feature of sudo for people who log in and out frequently (e.g., create and destroy terminal windows).
3. Because .bash_logout is only executed when a login shell exits.
Perhaps a similar but more elaborate solution could work to better mitigate this, though.
Always use a new shell for sudo. Always exit that shell when done.
Can't help wondering if this is how things will be under the upcoming UK Internet 'safety' measures (assuming Cameron survives that long.)