BlastDoor: iOS 14’s Shield Over Zero-Click Attacks
Apple has rightly been criticized for the ease with which a hacker could pwn an iPhone merely by sending it a specially crafted message. Bad actors such as NSO Group have made hay exploiting the fundamentally flawed iMessage-cum-kernel design.
But not anymore. And bizarrely, it’s Google that revealed the big change that came in iOS 14 last year.
Let’s dig in. In today’s SB Blogwatch, we get a bit nerdy for a Friday.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: celebrating the non-neuro-typical.
Talk Nerdy to Me
What’s the craic? Ryan Naraine reports—“Apple Adds ‘BlastDoor’ to Secure iPhones From Zero-Click Attacks”:
Apple has quietly added several anti-exploit mitigations into [iOS 14] in what appears to be a specific response to zero-click iMessage attacks observed in the wild. … The first big addition is a new, tightly sandboxed “BlastDoor” service that is now responsible for the parsing of untrusted data in iMessages.
…
Separately, Apple added logic into iOS 14 to specifically detect shared cache region attacks and new techniques to limit an attacker’s ability to retry exploits or brute force Address Space Layout Randomization (ASLR). … The new mitigations were discovered by Samuel Groß, a Google Project Zero security researcher. [He said they] made all four parts of a typical zero-click attack harder.
And Catalin Cimpanu adds—“Google researcher discovers new iOS security system”:
While iOS ships with multiple sandbox mechanisms, BlastDoor is a new addition that operates only at the level of the iMessage app. … Its role is to take incoming messages and unpack and process their content inside a secure and isolated environment, where any malicious code hidden inside a message can’t interact or harm the underlying operating system or retrieve user data.
…
Several security researchers had pointed out in the past that the iMessage service was doing a poor job of sanitizing incoming user data. … There had been multiple instances where security researchers or real-world attackers found iMessage remote code execution (RCE) bugs and abused these issues to develop exploits that allowed them to take control over an iPhone just by sending a simple text, photo, or video to someone’s device.
…
Groß said he believes that Apple finally listened to the security research community and improved iMessage’s handling of incoming content.
This is big. Samuel Groß takes a “look at iMessage in iOS 14”:
It is also now almost exactly one year ago since we published the Remote iPhone Exploitation blog post series, in which we described how an iMessage 0-click exploit can work in practice and gave a number of suggestions on how similar attacks could be prevented in the future. [So] now seemed like a great time to dig into the security improvements in iOS 14 in more detail and explore how Apple has hardened their platform against 0-click attacks.
…
Memory corruption based 0-click exploits typically require at least the following pieces: A memory corruption vulnerability, … a way to break ASLR, … a way to turn the vulnerability into remote code execution [and] (likely) a way to break out of any sandbox. … With iOS 14, Apple shipped a significant refactoring of iMessage processing, and made all four parts of the attack harder.
…
A new, tightly sandboxed “BlastDoor” service which is now responsible for almost all parsing of untrusted data in iMessages. [It] is written in Swift … which makes it significantly harder to introduce classic memory corruption vulnerabilities.
…
Historically, ASLR on Apple’s platforms had one architectural weakness: the shared cache region, containing most of the system libraries in a single prelinked blob, was only randomized per boot. … It allowed an attacker … to infer the base address of the shared cache and [so] ASLR. … With iOS 14, Apple has added logic to specifically detect this kind of attack, in which case the shared cache is re-randomized.
…
To limit an attacker’s ability to retry exploits or brute force ASLR, the BlastDoor and imagent services are now subject to a newly introduced exponential throttling mechanism … causing the interval between restarts after a crash to double. … The remainder of this blog post will now look at each of these three changes in greater depths … while also providing a walkthrough of how it was reverse engineered.
Samuel who? Let’s include IncludeSecurity:
Samuel, who published the research … is one of the best hackers I’ve ever met. He helped me code our interview challenge test that we still use (it’s that good!)
But if this was open source, there wouldn’t be the need to reverse-engineer it. Or so phantomfive seems to say:
Anyone who says that the iPhone “walled garden” is more secure than the Android system closes their eyes to these kinds of things.
And HHad3 goes furthh3r: [You’re fired—Ed.]
Open source aside, it would be great if any developer could do this on iOS. Unfortunately … Apple keeps the XPC API on iOS private, so that it is impossible for “normal” app developers to properly sandbox the more critical and exposed parts of their application. Only Apple can provide the described security for their messenger, but other messengers which face similar challenges (rendering untrusted content) cannot protect themselves.
Wait, did you say “open source aside”? Heed the righteous wrath of ctilsie242:
Because AOSP is available for all to look at, and it is well known how Android behaves, it is likely more secure. … You have no clue what is going on with iOS.
…
Android uses Linux users and groups, as well as SELinux to keep apps from getting out of their areas. Android also uses both loopback mounted filesystems and encrypting /data with dm-crypt.
…
With Android, you can have a boot PIN or password separate from your screen one, to ensure that a brute force attack is infeasible, especially with newer phones with TPMs that will cut things off and drop their stored keys.
…
iOS uses a variant of BSD jail() with a hefty helping of secret sauce. Do we know what or how the OS encrypts stuff?
But doesn’t all this cotton-wool protection slow down the phone? pjmlp brings the yes-but-ism:
It is the pursuit of speed at the expense of bounds checking that has brought us here.
Meanwhile, RealNeoMorpheus wants nothing to do with iThings:
I commend them for their efforts to secure iOS. But sadly, their draconian censorship of the app store and inability to even sideload an non approved app … will keep me away from their gold jail.
And Finally:
Hat tip: Miss Cellania
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Christian Santizo (via Unsplash)
