How Safari and iMessage Have Made iPhones Less Secure

The security reputation of iOS, once considered the world's most hardened mainstream operating system, has taken a beating over the past month: Half a dozen interactionless attacks that could take over iPhones without a click were revealed at the Black Hat security conference. Another five iOS exploit chains were exposed in malicious websites that took over scores of victim devices. Zero-day exploit brokers are complaining that hackers are glutting the market with iOS attacks, reducing the prices they command.

As Apple prepares for its iPhone 11 launch on Tuesday, the recent stumbles suggest it's time for the company to go beyond fixing the individual security flaws that have made those iPhone attacks possible, and to instead examine the deeper issues in iOS that have produced those abundant bugs. According to iOS-focused security researchers, that means taking a hard look at two key inroads into an iPhone's internals: Safari and iMessage.

While vulnerabilities in those apps offer only an initial foothold into an iOS device—a hacker still has to find other bugs that allow them to penetrate deeper into the phone's operating system—those surface-level flaws have nonetheless helped to make the recent spate of iOS attacks possible.

"If you want to compromise an iPhone, these are the best ways to do it," says independent security researcher Linus Henze of the two apps. Henze gained notoriety as an Apple hacker after revealing a macOS vulnerability known as KeySteal earlier this year. He and other iOS researchers argue that when it comes to the security of both iMessage and WebKit—the browser engine that serves as the foundation not just of Safari but all iOS browsers—iOS suffers from Apple's preference for its own code above that of other companies. "Apple trusts their own code way more than the code of others," says Henze. "They just don’t want to accept the fact that they make bugs in their own code, too."

Caught in a WebKit

As a prime example, Apple requires that all iOS web browsers—Chrome, Firefox, Brave, or any other—be built on the same WebKit engine that Safari uses. "Basically it’s just like running Safari with a different user interface," Henze says. Apple demands browsers use WebKit, Henze says, because the complexity of running websites' JavaScript requires browsers to use a technique called just-in-time (or JIT) compilation as a time-saving trick. While programs that run on an iOS device generally need to be cryptographically signed by Apple or an approved developer, a browser's JIT speed optimization doesn't include that safeguard.

As a result, Apple has insisted that only its own WebKit engine be allowed to handle that unsigned code. "They trust their own stuff more," Henze says. "And if they make an exception for Chrome, they have to make an exception for everyone."

"They should assume their own code has bugs."

Linus Henze, Security Researcher

The problem with making WebKit mandatory, according to security researchers, is that Apple's browser engine is in some respects less secure than Chrome's. Amy Burnett, a founder of security firm Ret2 who leads trainings in both Chrome and WebKit exploitation, says that it's not clear which of the two browsers has the most exploitable bugs. But she argues that Chrome's bugs are fixed faster, which she credits in part to Google's internal efforts to find and eliminate security flaws in its own code, often through automated techniques like fuzzing.

Google also offers a bug bounty for Chrome flaws, which incentivizes hackers to find and report them, whereas Apple offers no such bounty for WebKit unless a WebKit bug is integrated into an attack technique that penetrates deeper into iOS. "You’re going to find similar bug classes in both browsers," says Burnett. "The question is whether they can get rid of enough of the low hanging fruit, and it seems like Google is doing a better job there." Burnett adds that Chrome's sandbox, which isolates the browser from the rest of the operating system, is also "notoriously" difficult to bypass—more so than WebKit's—making any Chrome bugs that do persist less useful for gaining further access to a device.

Shady References

Another specific element of WebKit's architecture that can result in hackable flaws, says Luca Todesco, an independent security researcher who has released WebKit and full iOS hacking techniques, is its so-called document object model, known as WebCore, which WebKit browsers use to render websites. WebCore requires that a browser developer keep careful track of which data "object"—anything from a string of text to an array of data—references another object, a finicky process known as "reference counting." Make a mistake, and one of those references might be left pointing at a missing object. A hacker can fill that void with an object of their choosing, like a spy who picks up someone else's name tag at a conference registration table.

Comments are closed.