

Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root - tchap
https://twitter.com/hukl/status/307469987826761729

======
dazzawazza
From the FreeBSD man for date

    
    
      Only the superuser may set the date, and if the system securelevel (see
      securelevel(7)) is greater than 1, the time may not be changed by more
      than 1 second.
    
    

EDIT: so you need to be root anyway or have root access to change the date.

~~~
nwh
Users on MacOS can change the time without root access.

~~~
simias
Are you sure? If it is it sounds like a possible security issue. Time is
pretty sensitive as soon as certificates are involved. Many auth systems
assume the clock is properly synchronized across the system.

If that's true IMO that's the security issue, not the arguably strange
behaviour of sudo in a situation that should never occur.

~~~
dazzawazza
well from the terminal

    
    
       $ date 010101011970
       date: bind: Permission denied
       date: settimeofday (timeval): Operation not permitted
       [15:45:41][dazza@imac.internal:~]
    

From System Preferences you can indeed set the date back to 1970:

    
    
       $ date
       Fri  2 Jan 1970 00:56:44 BST
       [00:56:44][dazza@imac.internal:~]
    

but there is a little lock that you might need to unlock (with a user
password).

This does seem like a security issue on OSX.

~~~
pschastain
Changing back 01/01/1970 via Date & Time preferences doesn't need
authentication, but the exploit still didn't work, at least for me.

~~~
acdha
> Changing back 01/01/1970 via Date & Time preferences doesn't need
> authentication

This is not true but it can be confusing if you've authenticated at all
recently due to a grace period like sudo's.

~~~
nwh
I've never unlocked that panel, and I've rebooted recently, and still didn't
need authentication. Are you sure that's as right?

~~~
adestefan
The authentication for changing things via the System Preferences system is
independent of sudo and "sticks" across reboots.

------
RossM
CVE-2013-1775 [0] in case you're wondering.

[0]: <http://www.openwall.com/lists/oss-security/2013/02/27/22>

<http://www.ubuntu.com/usn/usn-1754-1/> <http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2013-1775>

~~~
raphinou
From the openwall link: > The vulnerability does not permit a user to run
commands other than those allowed by the sudoers policy.

------
trotsky
I see your wonky authentication bypass and raise you a local privilege
escalation that is 100% reliable on every distro that's shipped a 3.3-3.8
kernel (last 18 months or so)

<http://thread.gmane.org/gmane.linux.network/260061>

bad times :/

~~~
allerratio
Actually it is already fixed in many distros. For example in Arch Linux it
took a day to fix since the CVE request:
<https://bugs.archlinux.org/task/34005> <http://seclists.org/oss-
sec/2013/q1/420>

On the other hand my system here still crashes if I type file:/// with one big
letter.

------
jrockway
TL;DR: users in /etc/sudoers can run code as root with sudo.

~~~
hosay123
An evil person with e.g. a stolen SSH key can escalate privileges on a machine
without needing the user's password. It's not simply about sudo working as
designed, it allows bypassing sudo's user authentication entirely.

I can think of a handful of corporate machines (e.g. web servers) I've had
pubkey access on where sudo allowed the real admin to gain root from the same
account via sudo.

~~~
__alexs
How are they going to change the date without having a path to superuser
access already?

~~~
lukeschlather
They could potentially spoof the machine's NTP server.

~~~
devicenull
You mean, all of the NTP servers the machine uses. NTP will detect and reject
a single server reporting bad time (assuming you have at least 3 servers
configured, which is the recommendation).

You'd also have to do this when the NTP daemon first starts up, as:

    
    
           -g      Normally, ntpd exits with a message to the system  log  if  the  offset  exceeds  the  panic
                   threshold,  which  is  1000 s by default. This option allows the time to be set to any value
                   without restriction; however, this can happen only once. If the threshold is exceeded  after
                   that,  ntpd  will exit with a message to the system log. This option can be used with the -q
                   and -x options. See the tinker command for other options.

------
mnarayan01
From the vulnerability announcement, it seems like this only allows a user to
"set" NOPASSWD for that user's sudo regardless of what's in sudoers. It also
doesn't seem to allow escalation beyond what's in sudoers. Am I missing
something?

~~~
nsmartt
It sounds like you're overlooking the fact that software could do this without
your knowledge.

~~~
simias
Software that can do this could also just wait for you to run a sudo command
and then install a rootkit before the timeout is reached. Or it could keylog
your password.

On desktop machines getting root is almost useless, you have all the sensitive
information on the user account. Unless the attacker wants to install a
rootkit in the kernel or open raw sockets or stuff like that. But if they can
run arbitrary code with your UID you've probably already lost anyway.

~~~
nsmartt
I suppose that's true, but ideally there should be no situation in which you
give a program or script access to a terminal with sudo's timeout unreached.
Compromising information not stored on the machine should ideally require
root.

------
mpyne
Interesting! Does sudo somehow get confused about checking for a password at
all when the current date is the UNIX epoch?

I wonder, does this require the user to be listed in sudoers with any
privileges or is it just straight to root?

~~~
JoachimSchipper
This gives you only the privileges that a successful "sudo" would give you,
and requires a previous successful "sudo". It's a nice hack, but hardly the
end of the world.

~~~
brokentone
It is, however, the beginning of the UNIX world

------
subway
I wonder if it would be possible to walk back the date using an ntp mitm
attack.

~~~
_phred
Very, very difficult, unless the host relies on a single timesource. Best and
common practice is to use 3-4 sources from different organizations in the ISC
pool. It also wouldn't surprise me if most implementations of ntpd would have
further safeguards about going 40 years back in time; at the very least the
skew factor would make the clock change take a longgggg time to happen.

There are much easier attack vectors.

~~~
allerratio
Actually I had to write a ntp spoofer for an university class. With arpspoof
it is easy to manipulate all ntp traffic. At least ntpdate didn't complain
when you sent it some years forward or backward.

~~~
bathat
ntpdate won't complain because it's entire purpose is to set the time on a
system that isn't synchronized with the rest of the world. So it is expected
that the clock may have drifted by a substantial amount, and it is only meant
to be used occasionally. It is especially bad practice to run it from cron.

On the other hand, ntpd is a daemon that is meant to be run continuously. _It_
will complain if lower-strata time servers start jumping around, and has a
built-in mechanism for ignoring time servers that seem to be giving incorrect
time (compared to both other servers and the system's own idea of the current
time). Note that, if having accurate time is important, ntpd also supports
using external reference clocks with a pulse-per second connected to, for
example, a serial port.

------
grimtrigger
Can someone explain this a little more?

~~~
mpyne
sudo -k resets the "needs a password to be entered" flag by changing the last-
password-entered time to appear to be the UNIX epoch (time 0).

If you then change the date to be the same day (which can be done without root
permissions in modern Linux distros by using polkit or similar things), then
you can use sudo to run commands as root without a password.

Presumably, sudo checks the 'last-successful-login' entry alone before
deciding whether to require a password. It ends up thinking you've previously
successfully logged in even if you've never actually typed in the needed
password.

~~~
derekp7
So there are two ways I can see to fix this. Either make setting the time
always requires a password, or, add a signal that time-sensitive processes can
listen to that gets tripped whenever time is altered.

~~~
ScottBurson
There's a much simpler fix that is local to sudo. Sudo has to make the
decision of whether to require a password. Just change the line that says
something like:

    
    
      if (current_time - last_password_time > INTERVAL) require_password();
    

to

    
    
      if (last_password_time == 0
          || current_time - last_password_time > INTERVAL) require_password();

------
Nux
"Set your clock to 01.01.1970" BOOM, you can't! "date: cannot set date:
Operation not permitted"

------
moe
It may be worth noting that local privilege escalation vulnerabilities have
always been dime a dozen, this is just a more egregious one.

In your planning always keep in mind that anyone with shell-access to your
server can become root in one way or another, if he really wants to. There is
little "defense in depth" after that point.

------
thoughtsimple
After using sudo from the command line, just remember to run sudo -K (note the
capital-K) and you should be protected. The -K removes the timestamp which
makes it impossible to reset it to 1/1/70 with -k.

------
hukl
It works if you set your time through system preferences in OSX, Gnome and KDE
on some distros. Changing it on those desktop guis does not require admin
password. Also see:

<http://www.sudo.ws/sudo/alerts/epoch_ticket.html>

~~~
hukl
Also be sure to set the date including timezone offset.

On OSX run sudo -k, open date and time prefs. Set date to 1970-01-01 00:00:00
including timezone offset (+1 for CET) then run sudo su

------
ohazi
Debian unstable got a fix for this last night:

[http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_...](http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_1.8.5p2-1+nmu1/changelog)

------
rplacd
I'm surprised an issue that high-level's been able to lurk around for so long.

------
teknolust
Tried it on Debian Mint and it doesn't work. I can't set my clock without
sudo.

------
StavrosK
It doesn't work on Ubuntu, the clock gets reset back to 2010, for some reason.

~~~
tudorizer
Automatic time sync?

~~~
StavrosK
I set it to "manual" to change the date, and wouldn't it go back to 2013,
anyway?

------
lurker14
Why does "sudo -k" still exist, when it has obvious risks and is superseded by
"sudo -K".

Why does 'sudo -k' not check to see if a timestamp exists, and avoid creating
one if it doesn't yet exist?

------
p4bl0
Previous discussion, with a better link than to a tweet:
<https://news.ycombinator.com/item?id=5299326>

~~~
TheCapn
Doesn't look like a whole lot of discussion.

~~~
p4bl0
Well, ya. I should have said previous link.

