Researchers have made it easier to exploit a five-month-old security flaw that allows penetration testers and less-ethical hackers to gain nearly unfettered «root» access to Macs over which they already have limited control.
The authentication bypass vulnerability was reported in March and resides in a Unix component known as sudo. While the program is designed to require a password before granting «super user» privileges such as access to other users’ files, the bug makes it possible to obtain that sensitive access by resetting the computer clock to January 1, 1970. That date is known in computing circles as the Unix epoch, and it represents the beginning of time as measured by the operating system and most of the applications that run on it. By invoking the sudo command and then resetting the date, computers can be tricked into turning over root privileges without a password.
Developers of Metasploit, an open-source software framework that streamlines the exploitation of vulnerabilities in a wide array of operating systems and applications, recently added a module that makes it easier to exploit the sudo vulnerability on Macs. The addition capitalizes on the fact that all versions of OS X from 10.7 through the current 10.8.4 remain vulnerable. While the bug also affected many Linux distributions, most of those require a root password to change the computer clock. Macs impose no such restrictions on clock changes thanks to the systemsetup binary.
Mac users should realize that an attacker must satisfy a variety of conditions before being able to exploit this vulnerability. For one, the end-user who is logged in must already have administrator privileges. And for another, the user must have successfully run sudo at least once in the past. And of course, the attacker must already have either physical or remote shell access to the target machine. In other words: this exploit can’t be used in the kind of drive-by webpage attacks that last year infected some 650,000 Macs with the Flashback malware. This doesn’t mean it’s a non-issue though, since the exploit can be used in concert with other attacks to magnify the damage they can do.
«The bug is significant because it allows any user-level compromise to become root, which in turn exposes things like clear-text passwords from Keychain and makes it possible for the intruder to install a permanent rootkit,» HD Moore, the founder of the Metasploit project and the chief research officer at security firm Rapid7, told Ars. «I believe Apple should take this more seriously but am not surprised with the slow response given their history of responding to vulnerabilities in the open source tools they package.»
Apple representatives didn’t respond to an e-mail seeking comment for this post.
Post updated in third-to-last paragraph to changed «invoked» to «successfully run.»
Promoted Comments
Abhi BeckertArs Praetorian
jump to post
Liquid Snake X wrote:
Cowicide wrote:
Is Snow Leopard 10.6.8 affected at all?
It also uses sudo and doesn’t require a password for clock changes by default, so I would say… yes.
What version of sudo does 10.6.8 have? This bug only effects sudo 1.6 and greater. You can check by running `man sudo` and it at the end of the pan page (bottom left corner).
If you have 1.6 or greater, then I suggest creating a cron job that runs `sudo -K` every 5 minutes. This will delete the timestamp file… which will cause you to see the «there be dragons here» message every time you run sudo, but otherwise won’t harm anything.
557 posts | registered Sep 27, 2005
cheriffWise, Aged Ars Veteranet Subscriptor
jump to post
Haha, fun party trick at the office.. Sit at a macos terminal (with permission, of course)
$ systemsetup -setusingnetworktime off
$ systemsetup -setdate 01:01:1970
$ systemsetup -settime 10:02 // account for being in GMT+10 timezone
$ sudo -k
$ sudo su
# whoami
root
#
Nice.
182 posts | registered Nov 9, 2009
ScorpanSmack-Fu Master, in training
jump to post
How about running
$ sudo visudo
to edit the sudo config, and adding the line
Defaults timestamp_timeout=0
You’ll then be asked for a password at each sudo call, no matter how close to the previous successful call.