How Safari and iMessage Have Made iPhones Less Secure
Credit to Author: Andy Greenberg| Date: Mon, 09 Sep 2019 19:43:04 +0000
Security researchers say iOS's security woes stem in part from Apple putting too much trust in its own software's code.
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. Apple declined to comment on the record.
"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."
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.
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.
By contrast, Chrome's own version of WebCore includes a safeguard known as a "garbage collector" that cleans up pointers to missing objects, so they can't be mistakenly left unassigned and vulnerable to an attacker. WebKit by contrast uses an automated reference counting system called "smart pointers" that Todesco argues still leaves room for error. "There’s just so many things that can potentially happen, and in WebCore the browser developer has to keep track of all these possibilities," Todesco says. "It’s impossible not to screw up."
To Apple's credit, iOS has for more than a year implemented a security mitigation called isolated heaps, or "isoheaps," designed to make errors in reference counting impossible to exploit, as well as newer mitigations in the hardware of the iPhone XS, XS Max, and XR. But both Todesco and Burnett note that while isolated heaps significantly improved WebCore's security and pushed many hackers towards attacking different parts of WebKit, they didn't entirely prevent attacks on WebCore. Todesco says there have been multiple exploiting reference counting errors since isoheaps were introduced in 2018. "You can’t say they’re eliminated," Ret2's Burnett agrees.
Despite all those issues, and even as WebKit's flaws have served as the entry point for one iOS attack after another, it's debatable whether WebKit is measurably less secure than Chrome. In fact, a price chart from Zerodium, a firm which sells zero-day hacking techniques, values Chrome and Safari attacks equally. But another zero-day broker, Maor Shwartz, told WIRED by contrast that WebKit's insecurity relative to Chrome contributed directly to top prices for an Android exploit surpassing those for iOS. "Chrome is the most secure browser today," Shwartz says. "The prices are aligned with that."
Hackable flaws in iMessage are far rarer than those WebKit. But they're also far more powerful, given that they can be used as the first step in a hacking technique that takes over a target phone with no user interaction. So it was all the more surprising last month to see Natalie Silvanovich, a researcher with Google's Project Zero team, expose an entire collection of previously unknown flaws in iMessage that could be used to enable remote, zero-click takeovers of iPhones.
More disturbing than the existence of those individual bugs was that they all stemmed from the same security issue: iMessage exposes to attackers its "unserializer," a component that essentially unpacks different types of data sent to the device via iMessage. Patrick Wardle, a security researcher at Apple-focused security firm Jamf, describes the mistake as something like blindly opening a box sent to you full of disassembled components, and reassembling them without an initial check that they won't add up to something dangerous. "I could put the parts of a bomb in that box," says Wardle. "If Apple is allowing you to unserialize all these objects, that exposes a big attack surface."

More fundamentally, iMessage has innate privileges in iOS that other messaging apps are denied. In fact, non-Apple apps are cordoned off from the rest of the operating system by rigorous sandboxes. That means that if a third-party app like WhatsApp is compromised, for instance, a hacker still has to break through its sandbox with another, distinct technique to gain deeper control of the device. But Project Zero's Silvanovich noted in her writeup of the iMessage flaws that some of iMessage's vulnerable components are integrated with SpringBoard, iOS's program for managing a device's home screen, which Silvanovich writes has no sandbox at all.
"What I personally can’t understand is why they don’t sandbox it more," Linus Henze says of iMessage. "They should assume their own code has bugs, and make sure their code is sandboxed in the same way they sandbox the code of other developers, just as they do with WhatsApp or Signal or any other app."
Apple, after all, built the iPhone's sterling reputation in part by carefully restricting what apps it allowed into its App Store, and even then carefully isolating those apps within the phone's software. But to head off these high-profile incidents, it may need to reexamine that security caste system—and ultimately, to treat its own software's code with the same suspicion it has always cast on everyone else's.