Mac Firmware Security Is Completely Broken
The attack, according to a blog post published Friday by well-known OS X security researcher Pedro Vilaca, affects Macs shipped prior to the middle of 2014 that are allowed to go into sleep mode. He found a way to reflash a Mac’s BIOS using functionality contained in userland, which is the part of an operating system where installed applications and drivers are executed. By exploiting vulnerabilities such as those regularly found in Safari and other Web browsers, attackers can install malicious firmware that survives hard drive reformatting and reinstallation of the operating system.
The attack is more serious than the Thunderstrike proof-of-concept exploit that came to light late last year. While both exploits give attackers the same persistent and low-level control of a Mac, the new attack doesn't require even brief physical access as Thunderstrike did. That means attackers half-way around the world may remotely exploit it.
As a general user you shouldn’t, in theory, be much worried with this bug more than you were with Thunderstrike. This is a bug more interesting to attack targeted users than mass exploitation, although a drive-by exploit is definitely feasible. There are easier and cheaper attacks available against you the general user. As a reminder the latest Mac botnet infected around 17k users just by asking them for administrator privileges. Sophisticated attacks are not required when simple things still work.
6 Comments RSS · Twitter
My favourite quote is this one: "you can overwrite the contents of your BIOS from userland and rootkit EFI without any other trick other than a suspend-resume cycle, a kernel extension, flashrom, and root access."
Am I the only one curious about the new definition of "userland"? If hackers have installed a kernel extension, flashrom, and gained root access, I think we can safely call the machine "compromised" at that point.
@john It's a bit confusing but IMHO, he's describing a chain of events/actions.
1. Downloading a rootkit from the current standard user session.
2. Using it to gain root access and load the kernel extension (once loaded, you don't need the kext anymore on disk or the rootkit on disk)
3. Waiting/hoping for a suspend-resume cycle in the current user session to corrupt the firmware.
In the P.S., he added a step 0: Exploiting a 0day in a browser/app to execute this on a targeted computer.
"Am I the only one curious about the new definition of "userland"? If hackers have installed a kernel extension, flashrom, and gained root access, I think we can safely call the machine "compromised" at that point."
1) The first-step compromising can be accomplished from 'userland'. (And if I understand correctly, simply from Safari usage by landing on the wrong site.) Thus the second-step UEFI compromising can also be ultimately accomplished from 'userland', even though an intermediate step is employed.
2) A remotely compromised machine prior to this exploit could at least be un-compromised by wiping the hard drive, and re-installing the system from scratch, or from a clone. With this exploit, that option is gone. Once compromised, forever compromised.
-----
Also, FWIW, I'm highly dubious about Pedro Vilaca's conclusion in the pullquote above. This type of drive-by attack seems far simpler to accomplish on a mass scale than social engineering attacks...
So, what's the solution here?
My working assumption is that OS X is inherently vulnerable to 0-days. That there is fundamental architectural problem here beyond social engineering.
They'll generally be patched at some point for current version OS's, and for hardware bought within the last year, but again, 0-days are 0-days.
What are the vectors? Beyond untrustworthy 3rd party software, should we assume the non-internet-plugin vector is exclusively JavaScript? Should we assume Chrome is, while perhaps safer than Safari, not ultimately safe? Should we assume Preview, even old versions, are essentially safe?
So, if we can assume JavaScript is the vector, then should we only be running JavaScript in a VM?
@Chucky I don’t know. We got all this degradation of Safari to make it more secure, and it’s still not secure? Even though the rendering engine is sandboxed?
"We got all this degradation of Safari to make it more secure, and it’s still not secure?"
rootpipe FTW!
IDK either, of course. FWIW, this is why I pressed you to add an esoteric pref to EagleFiler to import sans JavaScript.
I've been surfing mainly without JavaScript since about 1998, with occasional forays into select JavaScript sites. But now I'm seriously considering setting up a VM for all of my JavaScript forays. I figure that's enough abstraction to avoid this kind of exploit.
(I know my older hardware will never get UEFI patched. And neither will anyone else's, of course. Your machine is 2 years old? As they say a lot in the basic cable re-runs of Glengarry Glen Ross, "forget you!" I'm just glad I picked up a couple of used spare machines a bit ago. Going forward, the UEFI nonsense makes buying used machines a dodgy enterprise.)
