The Expert's View with Jeremy Kirk

Application Security , Endpoint Security , Governance & Risk Management

Weak Drivers Key to Compromising macOS

Researcher Patrick Wardle Finds Ways to Get Inside the All-Important Kernel
Weak Drivers Key to Compromising macOS

When he's not surfing Hawaiian waves, Patrick Wardle spends considerable time figuring out new ways to hack Apple's operating system, macOS. Although Apple has maintained for more than a decade its security superiority over Windows, it's only truly hardened the OS in the last few years.

See Also: Live Webinar | Navigating Identity Threats: Detection & Response Strategies for Modern Security Challenges

Wardle, who is director of research with Synack, says the days of finding a single software flaw in say, Safari, that yields full control over a Mac are long over. From isolating apps in sandboxes to code signing to the sealing of critical OS areas using System Integrity Protection, or SIP, hackers now face imposing obstacles.

His latest research, presented last weekend at the Ruxcon security conference, has focused on Apple's I/O kit, the company's platform for writing software drivers - the code for working with a computer's software and hardware.

"It's just tough to write secure drivers, and a lot of the code is very, very, very complicated," Wardle says. "From a bug hunter's view, it's a very good place to look."

Many bugs have been found in I/O kit drivers, Wardle says. Some of those drivers have authority to interact with macOS's kernel, the core, most sensitive part of the operating system. That's the place where hackers want to be, especially because Apple curtailed the power of root access with SIP.

"Nowadays on modern Mac operating systems, you pretty much need a kernel vulnerability in order to really own or infect the box in a good way from the malware's point of view," Wardle says.

Apple highly restricts what apps can get access to the kernel. Most applications don't need access to the kernel. But security applications do because it's a crucial area that needs monitoring.

In order to get kernel access, developers must apply for a kernel-signing certificate, and Apple closely vets those applicants. It even took Wardle, who frequently corresponds with Apple security's team, awhile to obtain one.

Cracking Kernels

Wardle actually started investigating how to get access to the kernel almost three years ago. As part of this research, he took a look at Little Snitch, a network monitoring tool made by Objective Development Software, an Austrian company.

He found a way to exploit Little Snitch in order to get kernel access. But there was a problem: An obscure bug on Apple's side prevented the exploit. In a type of perverse reporting process, Wardle reported that bug to Apple, which took almost two and a half years to fix it. But once it was fixed, his Little Snitch attack worked. He reported the Little Snitch flaw, a buffer overflow, to Objective Development Software, which fixed it within three weeks.

For a successful attack to be executed remotely, Wardle says he would need another flaw in an application such as Safari to get on the system. Then, the Little Snitch driver could be loaded and the exploit launched.

It doesn't matter whether the user on the system at the time has root access or is a guest user, he says. "You can escalate from that all the way to the kernel because there's an installed kernel driver that has a bug," he says.

Because Little Snitch's kernel driver is signed, there's no protesting from AV products or other Apple security features, such as SIP, about the attack. While patching its bug, Little Snitch also fixed a behavior that allowed any code to talk to its kernel driver. Now Wardle says the application only allows its own components to talk to the driver.

"So even if there is other buggy code, it kind of shuts down that attack surface," Wardle says.

What can users take away from the findings? Be aware that some applications, particularly security ones, may have kernel-level access, so it's good to be judicious when considering whether to install one. And for driver developers: Be very careful, because a mistake could be very bad for users.



About the Author

Jeremy Kirk

Jeremy Kirk

Executive Editor, Security and Technology, ISMG

Kirk was executive editor for security and technology for Information Security Media Group. Reporting from Sydney, Australia, he created "The Ransomware Files" podcast, which tells the harrowing stories of IT pros who have fought back against ransomware.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.co.uk, you agree to our use of cookies.