
Mac OS X Sudo Password Bypass - llambda
http://packetstormsecurity.com/files/122965
======
hcarvalhoalves
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.

------
benjamincburns
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.
    

[http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time...](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html#tag_13_76)

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](http://stackoverflow.com/q/18539724/203705)

2: [http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-
DISCIPLINE](http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE)

~~~
audidude
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.

~~~
benjamincburns
No CLOCK_MONOTONIC in OS X?

 _In a David Tennant voice:_ Wait, what?? What?!

    
    
      ~$ grep CLOCK_MONOTONIC /usr/include -rn
      ~$
    

Ahh, it's in the POSIX realtime extension... Dammit.

Apparently [1] one solution would be to #IFDEF DARWIN the following, as on
Darwin SYSTEM_CLOCK is _supposed_ to be a monotonic boot clock.

    
    
      #include <mach/clock.h>
      #include <mach/mach.h>
      
         ...
      
      clock_serv_t cclock;
      mach_timespec_t mts;
    
      host_get_clock_service(mach_host_self(), SYSTEM_CLOCK,
      &cclock);
      clock_get_time(cclock, &mts);
      mach_port_deallocate(mach_task_self(), cclock); 
    

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...

~~~
simscitizen
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.

------
Someone
_" If [...], it is possible to become the super user by running `sudo -k` and
then resetting the system clock to 01-01-1970"_

Can users reset the Mac OS X system clock without being an admin?

~~~
mikeash
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.

~~~
gpvos
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.)

------
npongratz
sudo offers updated binaries for OS X 10.5 and up so you don't have to wait
for Apple:
[http://www.sudo.ws/sudo/download.html#binary](http://www.sudo.ws/sudo/download.html#binary)

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](http://www.sudo.ws)

2) Untar, ungzip, go to resulting source directory

3) Run configure, telling it to overwrite the vulnerable sudo

    
    
        configure --prefix=/usr/bin
    

4) Compile

    
    
        make
    

5) Install

    
    
        sudo make install
    

6) Delete the old sudo you backed up in (0)

See also the sudo installation notes here:
[http://www.sudo.ws/sudo/install.html](http://www.sudo.ws/sudo/install.html)

~~~
bits
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.

~~~
npongratz
You're absolutely right on all counts. You caught me writing that sloppily
from memory. Thank you for the corrections!

------
gnoe
Here's a workaround until Apple updates sudo, add the following to you
/etc/sudoers file:

    
    
      Defaults timestamp_timeout=0

------
wcchandler
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...

~~~
traviscj
A few points:

\- 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?

~~~
wcchandler
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.

~~~
4ad
The admin group is what it's used for sudo by default.

------
aroch
Appears to be fixed in 10.8.5, the MSF posted doesn't work under 10.8.4 for me
either.

------
Osiris
Can someone explain why resetting the clock will give sudo access without
requesting a password?

~~~
uxp
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.

------
vhost-
Does anyone know how they fixed this in sudo? I would be interested in knowing
how they do a TTL without using the system time for comparison.

------
rcthompson
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)?

~~~
KMag
Repeat after me "timestamps should always be UTC. Time zones and DST should be
left to the display layer".

In any case, as a security measure, preventing the clock from being set before
the compile time is a bandaid for a bullet hole.

------
deathanatos
Setting the system clock in Mac OS X doesn't require root privileges?

------
marcosscriven
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?

------
stcredzero
No security that needs time should be based on an insecure clock. Is there any
kind of network "verified time" facility using PKC?

~~~
KMag
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.

------
fjcaetano
Well... this is dangerous...

------
crunchcaptain
Why not add:

sudo -K

to .bash_logout

~~~
theg5prank
1\. Because that doesn't fix the vulnerability, only narrows the window in
which the exploit works.

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.

~~~
thoughtsimple
This is probably good enough for most purposes if the user is somewhat
informed.

Always use a new shell for sudo. Always exit that shell when done.

------
ragsagar
Unable to access this url from UAE :-(

~~~
ttctciyf
Also unable to access it from a Virgin train in the UK: 'restricted' because
the site is considered 'malicious or inappropriate'.

Can't help wondering if this is how things will be under the upcoming UK
Internet 'safety' measures (assuming Cameron survives that long.)

------
hunkop
This non-bug was discussed last year.

~~~
mherdeg
Are you sure about "last year"? I thought the bug was assigned CVE-2013-1775
and discussed in late Feb 2013.

~~~
uxp
"Last Year", in internet time maybe. Here's the original CVE:

[https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-17...](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1775&cid=3)

------
aioprisan
doesn't work on 10.8.4 for me

