Researcher Discloses Critical macOS Privilege Escalation Bug

There has been a lot of buzz lately about Meltdown and Spectre, which are really worrisome speculative execution vulnerabilities that affect most Intel, and many ARM and AMD CPUs. Companies like Microsoft and Apple are busy making sure that millions of users worldwide have patches that they can install.

It’s probably the biggest cybersecurity story so far in 2018. But amidst all of that commotion, here’s news that you may have missed. Security researcher Siguza discovered a critical macOS vulnerability which affects versions of macOS and OS X from the latest 10.13 High Sierra perhaps all the way back to 10.2 Jaguar. Siguza calls it IOHIDeous.

What’s IOHIDeous?

IOHIDeous can be exploited by unprivileged users to acquire privileged kernel-level read and write access. So, if an attacker knows how to exploit IOHIDeous, your Mac is theirs to control however they want.

Think of the sensitive data that could be in a Mac’s HDD or memory at any time. Many users do online shopping and banking on their Macs. It’s also very likely that there are tokens for iTunes and App Store accounts, and possibly even web tokens for services such as Apple Pay. An attacker could really ruin a Mac user’s life by exploiting IOHIDeous.

IOHIDeous is named after the IOHIDSystem class of functions in macOS. IOHIDSystem is an input/output device driver which allows interaction directly with the kernel. Learning about IOHIDSystem should be lots of fun for Mac geeks who want to learn more about the inner workings of macOS. It contains a lot of different functions that Mac app developers could find useful for various purposes, including many with the cursor, mouse and keyboard.

IOHIDSystem has lots of features which differ a little bit between different versions of macOS/OS X. So, there are some aspects of IOHIDeous that can be used to exploit all versions, and some other aspects which affect only Sierra or High Sierra.

Siguza Explains IOHIDeous

I have no experience with macOS or iOS development. That’s Siguza’s area of expertise, and he explains the IOHIDeous exploit in full detail on GitHub. Here’s the Coles Notes interpretation with the most important paragraphs I could find:

This is the tale of a macOS-only vulnerability in IOHIDFamily that yields kernel r/w and can be exploited by any unprivileged user.

IOHIDFamily has been notorious in the past for the many race conditions it contained, which ultimately led to large parts of it being rewritten to make use of command gates, as well as large parts being locked down by means of entitlements. I was originally looking through its source in the hope of finding a low-hanging fruit that would let me compromise an iOS kernel, but what I didn’t know then is that some parts of IOHIDFamily exist only on macOS – specifically IOHIDSystem, which contains the vulnerability discussed herein.

The exploit accompanying this write-up consists of three parts:

· poc (make poc)
Targets all macOS versions, crashes the kernel to prove the existence of a memory corruption.

· leak (make leak)
Targets High Sierra, just to prove that no separate KASLR leak is needed.

· hid (make hid)
Targets Sierra and High Sierra (up to 10.13.1, see
README), achieves full kernel r/w and disables SIP to prove that the vulnerability can be exploited by any unprivileged user on all recent versions of macOS.”

“In order to understand the attack surface as well as the vulnerability, you need to know about the involved parts of IOHIDFamily. It starts with the IOHIDSystem class and the UserClients it offers. There are currently three of those:

· IOHIDUserClient

· IOHIDParamUserClient

· IOHIDEventSystemUserClient”

“IOHIDSystem restricts the number of IOHIDUserClients that can exist at any given time to exactly one. This is specifically enforced by the evOpenCalled class variable, which is set to true when an IOHIDUserClient is spawned and to false again when it is closed. This variable is checked in IOHIDSystem::evOpen, which in turn is called from IOHIDSystem::newUserClientGated (so we can’t even race it).

Bottom line, there can only be one IOHIDUserClient at any given moment, and chances are that when your code runs, WindowServerwill be long up and running with its UserClient already. So snatching that is not straightforward, but we’ll get to that later. For now we’re gonna look at what it actually uses that UserClient for.

The Aftermath

Siguza used GitHub to announce his findings. Someone on Twitter asked him why he didn’t sell it to a government agency or in the blackhat market:

“Can I ask, why not sell it? I'm sure some government or blackhat would have paid a lot for it? Or are you just the type of person who can't be reasoned with, who doesn't care for money and just want to watch the world burn?”

Siguza replied:

“My primary goal was to get the write-up out for people to read. I wouldn't sell to blackhats because I don't wanna help their cause. I would've submitted to Apple if their bug bounty included macOS, or if the vuln was remotely exploitable.

Since neither of those were the case, I figured I'd just end 2017 with a bang because why not. But if I wanted to watch the world burn, I would be writing 0day ransomware rather than write-ups.”

I asked Siguza if he knew anything about Apple’s reaction to his discovery:

“On a technical level I'm pretty sure they've long since fixed the bug and will be shipping that in the next update.

They've also opened a case in their bug tracker and associated my email address with it, I imagine they're going about it as if I had reported it directly to them. It's possible that someone was called in to fix it after I published my write-up, but I don't know whether that actually happened.

And I talked privately to an Apple security engineer who told me they had found the bug as well a while back, but hadn't verified the patch that had been applied afterwards, which (now quite obviously) didn't actually fix the vulnerability. But they said at least collisions with public bugs gives them some reassurance and stresses the importance of the work they're doing.

Interestingly enough, they also told me that they had started auditing IOHIDFamily after I had tweeted about the vulnerability I found. I was wrong about it requiring root. Other than that, I don't think any department at Apple or the company as a whole is really reacting to it.”

I’m sure Apple’s macOS development team are super busy right now with both the patching of Meltdown and IOHIDeous on their plate. In the wake of all of this, perhaps macOS should be added to their bug bounty program? It would’ve been better for the world to learn about the vulnerability after Apple patched it.

That’s what Apple, Microsoft, and Intel tried to do with Meltdown. They knew about the vulnerability before everyone learned about it in January. They were busy developing patches with plans to announce Meltdown once the patches were all available for installation. But someone leaked the news early.

Considering IOHIDeous and Meltdown, I think the big story is can vendors keep a vulnerability secret until they’ve had a chance to patch it?

About Kim Crawley

Kimberly Crawley spent years working in consumer tech support. Malware-related tickets intrigued her, and her knowledge grew from fixing malware problems on thousands of client PCs. By 2011, she was writing study material for the InfoSec Institute’s CISSP and CEH certification exam preparation programs. She’s since contributed articles on information security topics to CIO, CSO, Computerworld, SC Magazine, and 2600 Magazine. Her first solo-developed PC game, Hackers Versus Banksters, and was featured at the Toronto Comic Arts Festival in May 2016. She now writes for Tripwire, Alienvault, Cylance, and CCSI’s corporate blogs.

The opinions expressed in guest author articles are solely those of the contributor, and do not necessarily reflect those of Cylance.