A few weeks ago my Vaio toasted out. I’ve been using an old Dell laptop as a replacement, which was previously being used as a NAS server box. To replace the NAS, I dusted off my sister’s old Macbook and tried to wrestle OS X into shape, including writing a patch for rsync to deal with OS X’s awful UTF-8 semantics (NFC vs NFD), but this is for another post. While waiting for things to transfer, I was auditing my colo, and I typed find / -type f -perm -4000 into the Mac’s SSH session by accident. Before I could Ctrl+C out of it, I noticed “hey, weird, why’s Tunnelblick need an SUID helper?”.
Coincidentally, a friend was just touting the high quality UNIX tools OS X has to offer. I was skeptical.
It turns out that the two most popular OpenVPN client/managers for Macintosh, Viscosity and Tunnelblick, both use incredibly insecure SUID helpers.
When either Viscosity or Tunnelblick is installed, an unprivileged user can elevate permissions to become root (the Administrator user).
Here are the relevant links:
| Tunnelblick Vulnerability | Viscosity Vulnerability |
|---|---|
|
|
| CVE Assignment for Tunnelblick | |
|---|---|
| CVE-2012-3483 | 1. A race condition in file permissions checking can lead to local root. – TOCTOU |
| CVE-2012-3484 | 2. Insufficient checking of merely 0:0 744 can lead to local root on systems with particular configurations. |
| CVE-2012-3485 | 3. Insufficient validation of path names can allow for arbitrary kernel module loading, which can lead to local root. |
| 4. Insufficient validation of path names can allow execution of arbitrary scripts as root, leading to local root. | |
| 5. Insufficient path validation in errorExitIfAttackViaString can lead to deletion of files as root, leading to DoS. | |
| CVE-2012-3486 | 6. Allowing OpenVPN to run with user given configurations can lead to local root. |
| CVE-2012-3487 | 7. Race condition in process killing. – TOCTOU |
| CVE Assignment for Viscosity | |
| CVE-2012-4284 | Insufficient validation of path names can allow execution of arbitrary python code as root, leading to local root. |
Well, good to see you back in the saddle.
You do of course know that you can always get root on any mac just by holding down apple-s during boot. After that, the other security holes seem sort of insignificant.
I think you are missing the point of such exploits in general. We use them because most of the time we don’t have physical access to the machine, or even if we did a reboot and a somewhat lengthy period of physical tampering is often out of the question.
Elevating privileges when one has a local shell, perhaps by combining it with another exploit that runs something as the user being exploited, is crucial and important. With all due respect, and I don’t know you, but I believe making a comment about how a privilege-escalating exploit is useless because you can always just boot into single-user mode shows complete lack of any real-world experience. We benefit from these things because we DON’T have local, physical access. A lot of times we just have user privileges. Apple though does have a lot of applications using it’s great Sandbox system, and the more that use this the safer the system will be against such an attack leveraging the running of Tunnelblick because the application (perhaps a web browser) cannot run Tunnelblick to begin with.
This logic applies to pretty much any machine to which you have physical access, because you can simply boot into an “emergency boot disk” and mount the filesystem and over-write any user passwords preventing you from logging in or add a user with superuser privileges. It’s pretty straight-forward. This isn’t some revelation or something that most Apple users should be made aware of, because it effects everything else out there as well. However, I will give it to you that the single-user mode on Apple makes things a little more simple but it’s not like the obstacle of inserting a boot-disk medium of some kind had been too great to begin with!
ALSO — If the Mac machine is encrypted via Filevault v2 (or PGP Whole Disk Encryption) OR Open Firmware PW protection is on, Apple-S of course won’t work because the filesystem cannot be mounted without a key or the Openfirmware prevents it. So no, you can’t just magically get root on any Mac by pressing Apple-S at boot. However, with the Openfirmware protection one could still just boot the user’s disk and over-write passwords and install software and hook it to launch at start-up via launchd and replace it back into the computer. However, with file-system encryption this of course would not be possible.
Just my two cents.
We hackers care about getting shell and then escalating to root, if we have physical access then there is no privesc needed for elevated access…as you alluded to oh wise Mitch.
Well, aren’t you oh so clever. “We hackers” also know that if a system is so sloppy as to not tell its users about things like the apple-s boot functionality (which the overwheliming majority of Mac users don’t know about – go ask some if you don’t believe me), it’s also likely to be sloppy in many other ways — as Jason discovered.
Hey – you must be really smart. You use words like “privesc”!
[...] discovered and reported to the vendor by Jason A. Donenfeld the 2012-08-11 Metasploit PoC provided the [...]
[...] discovered and reported to the vendor by Jason A. Donenfeld the 2012-08-11 Vulnerability corrected by the vendor the 2012-08-30 Metasploit PoC provided the [...]