Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

twitter.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#61

Post by allerratio »

trotsky wrote: post #27

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 :/

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.

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#62

Post by allerratio »

_phred wrote: post #35
subway wrote: post #32

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

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.

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.

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#63

Post by acdha »

pschastain wrote: post #46
dazzawazza wrote: post #31

Earlier quoted context omitted.

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…

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

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

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#64

Post by acdha »

halviti wrote: post #50
_phred wrote: post #35

Earlier quoted context omitted.

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.

It doesn't matter how many time sources there are. If you're doing an MITM attack, it's just as easy to fake multiple sources as it is to fake one.

This isn't always true: it all depends on where you [the attacker] are. If you've done something like compromise part of a large organization's network, it's entirely plausible that you could spoof either their internal NTP server or time.apple.com but not both.

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#65

Post by kgo »

nwh wrote: post #16
dazzawazza wrote: post #14

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.

Users on MacOS can change the time without root access.

But most of the time, someone using MacOS has physical access to the box. They can always just boot up as single user and BOOM root:

http://support.apple.com/kb/ht1492

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#66

Post by papsosouid »

subway wrote: post #32

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

No, ntpd adjusts the skew, not the actual time. NTP is specifically designed to prevent time from going backwards because that can cause all sorts of problems with tons of software. It only slows down and speeds up the clock to keep it in sync.

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#67

Post by ScottBurson »

derekp7 wrote: post #28
mpyne wrote: post #6

Earlier quoted context omitted.

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 alon…

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.

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();

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#68

Post by bathat »

allerratio wrote: post #62
_phred wrote: post #35

Earlier quoted context omitted.

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.

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.

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.

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#69

Post by jrockway »

hosay123 wrote: post #23
jrockway wrote: post #15

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

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.

Can't the evil person with said access just wait until the person legitimately runs sudo? Today's exploit just allows the attack to happen more quickly, if the attacker happens to be able to change the time on the clock by a few billion seconds without escalated access.

Re: Run sudo -k, set your clock to 01.01.1970, run sudo su and boom you're root

#70

Post by nwh »

acdha wrote: post #63
pschastain wrote: post #46

Earlier quoted context omitted.

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

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

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