Why you shouldn't freak out about this week's scary-sounding Mac exploits

One set of researchers explains how a modification to your Macintosh's boot-up firmware can persist undetectably and spread through peripherals to other computers. Another researcher's work from a month ago is found in the wild, installing adware through a hidden escalation in user privileges. Both sound terrible, but neither is quite what it seems.

One set of researchers explains how a modification to your Macintosh's boot-up firmware can persist undetectably and spread through peripherals to other computers. Another researcher's work from a month ago is found in the wild, installing adware through a hidden escalation in user privileges. Both sound terrible, but neither is quite what it seems.

De-escalate your privilege, buddy

A month ago, a security researcher who has found previous flaws in iOS, Stefan Esser, documented a problem in OS X about which he didn't warn Apple in advance. Starting in Yosemite, OS X allowed software to log errors to an arbitrary file. Esser discovered that this could be used maliciously to write to files that only a root user should be able to. He took that weakness to demonstrate how one might escalate privileges, allowing a regular user without administrator or root access to run any software he or she wishes.

I didn't cover this back when it was announced for three reasons: First, I'd prefer to not give attention to researchers who opt out of following the industry standard of revealing zero-day (immediately exploitable and unpatched) security flaws to the company or organization responsible for updating the software. This is unavoidable when it's severe enough, because people need to be informed about risks and mitigations.

Revealing zero-days injures end users at the expense of making a point about one's frustration with a firm, or for those who simply don't care, it demonstrates a lack of ethics about one's actions. If the motivation is disgust with Apple or another company's responsiveness to security flaws, I've seen other researchers just as effectively make the point by disclosing 60 days or several months after an initial flaw goes unpatched if the software maker is truly avoiding the problem. This was the case with NetUSB in May, a flaw that affect millions of routers, and which only some affect companies chose to act on.

My second reason: To exploit this flaw, one has to have a way to run software as a local user. This requires a separate zero-day that acts as a trigger, or relying on the naiveté of a user who installs software from random sites--not from Apple or known third-party developers.

The flaw isn't insignificant: it's truly dangerous and severe. But because exploiting it almost certainly requires users to engage in behavior that is already extremely risky, a privilege escalation isn't per se more severe than them installing software from download sites, via torrents, or through other untrusted sources and using an administrator password when prompted.

Third, I assumed it was the sort of thing that would be quickly patched, because it's such a trivial error, rather than a deeply nested part of OS X that would require new plumbing. In fact, Apple had received a report well before Esser's disclosure, and was already working on the problem.

Unfortunately, before Apple made the fix, malware was discovered in the wild this week in an adware installer--that's an installer for legitimate software that also adds adware with affiliate programs. These malicious installers don't hack a computer, so much as provide a revenue stream for those who release them.

Apple tells me that the latest developer beta of 10.10.5 contains the fix, which Esser confirmed a few days ago; OS X 10.11 El Capitan approaches this particular feature differently, and didn't suffer from the flaw. The date for 10.10.5's release wasn't disclosed.

The adware installer found in the wild that exploits this flaw used a signed developed certificate, which Apple has revoked. Apple has further added a signature to XProtect, its anti-malware database, which should be updated by this writing to prevent the original installer and ones using similar code from running.

Esser isn't wrong to be frustrated at the uneven pace by which Apple fixes system flaws. The company is sometimes lightning fast, and sometimes lets issues lag for months or longer. But it's hard to support this form of disclosure unless one is certain Apple is ignoring the problem because Apple certainly isn't harmed in any substantive way by being "punished" with no advance warning. Users are.

Giving it the boot

Also this week, researchers said they had found vulnerabilities in Apple's bootloader software, EFI (Extensible Firmware Interface), different forms of which are widely used for all modern personal computers, whether they run OS X, Windows, or a Unix variant. EFI resides in firmware, and launches when a computer is powered up or restarted, initializing hardware and loading the operating system. (In the not-that-long-ago days, the PC world used BIOS, for basic input/output system, which EFI replaces.)

One of the two researchers demonstrated Thunderstrike earlier this year, a way of modifying EFI firmware through Thunderbolt hardware, which can contain the equivalent of firmware extensions via built-in option ROMs. Option ROMs are designed to extend EFI to support specific hardware features--hence the term "extensible" in EFI's name. Not enough checking was done to prevent malicious software from running and patching EFI. The 10.10.2 update closed the hole that allowed Thunderstrike to work, but researcher Trammell Hudson said months ago that other vulnerabilities remain if one can gain physical access to a Mac.

He and Xeno Kovah plan to show a demonstration of Thunderstrike 2 this week in Las Vegas at the Def Con computer security conference. This variant takes a different approach to the same sort of attack, and more worryingly can spread as a worm among infected devices. However, it still requires several steps to accomplish its task.

The worm has to be delivered, which requires either physical access (through a malicious or innocent party with an infected device) or via a separate exploit to install or a way to convince a user, as with the escalation flaw discussed above. Once the malware is loaded, the malware copies itself to any other attached Thunderbolt device's option ROMs, including peripherals as simple as a Thunderbolt gigabit ethernet adapter.

When a Mac is next restarted with an infected option ROM, the malicious software is added to its EFI firmware, providing a new vector. Any infected peripheral that's shifted from that Mac to another spreads the malware. While Apple checks for the integrity of firmware updates before they're installed, it doesn't otherwise check option ROMs or EFI firmware at other points.

Apple says that as of 10.10.4 (released in June), the demonstration that Kovah and Hudson plan to show will not work, as they've patched the vector used. Via email, Hudson pointed me to an update on his site on Wednesday that acknowledges one avenue of attack was shut down, but others remain, including using option ROMs to spread their worm. Apple says it's investigating these other reported weaknesses.

But it's crystal clear from the researchers' work that more fundamental changes need to be made to ensure that holes aren't just plugged. Two months ago, yet another EFI flaw was found--and quickly patched by Apple as part of the 10.10.4 release.

A rethink of firmware integrity is needed, and not just by Apple. The two researchers more broadly found problems across the industry in EFI bootloaders. As I noted two months ago, peripheral firmware appears to already have been exploited by national-security agencies, and would thus also be a likely target for criminals as well. This kind of attack isn't theoretical nor just a good demo. Computer vendors need to step up to the new state of firmware risks.