BlastDoor Hardens iMessage Against Malware Assaults

Last week, Google Project Zero’s Samuel Groß published a lengthy and technical blog post explaining his findings. If you recognize Groß’s name, that’s because he is frequently credited in Apple’s security updates with finding bugs, as is the project he works for at Google. If you want the gory details, read his post, but here’s the end-user version.

 

iMessage has reportedly been exploited a number of times in the wild with so-called “zero days,” or flaws that can be exploited to gain access to a system, app, or service that its maker isn’t yet aware of. The activist researcher organization Citizen Lab released a report on 20 December 2020 about one such attack used extensively in 2020. It appears that iOS 14 stifles that attack.

Google’s Groß decompiled and examined the iMessage code in Big Sur and discovered that Apple had replaced iMessage’s previous simplified message handling, which had many points of weakness. The new code has a series of components you can think of as a set of scanners and disassembly stations that prevent a bomb from passing into a secure location. Groß says that Apple calls this BlastDoor in its innards. The technology is also present in iOS and iPadOS, as far as he can determine. (iOS and iPadOS are more locked-down than macOS, making it somewhat harder to be sure.)

Before BlastDoor, incoming messages passed through a single monolithic process that handled every message-related task: addressing, integrity, attachments, notification of receipt, and more. If a maliciously crafted message or attachment could crash that message handler, it opened the operating system up to abuse.

Imagine iMessage as an office building protected by an automated, unmonitored package receiving dock with a keyboard to enter a recipient’s name and a slot for inserting boxes. Sometimes attackers would do the equivalent of putting chewing gum over a sensor, which confused the system into letting the attacker open a hatch and enter the building—and then open many doors once inside.

iMessage was also susceptible to poking and prodding: an attacker could try different kinds of behavior to see if a message was delivered successfully—if not, that revealed critical information. And an attacker could try to crash the message handler indefinitely, although the device’s owner might eventually notice.

BlastDoor compartmentalizes, or sandboxes, each step in message processing. Sandboxing is a well-known system design technique Apple and many other firms have increasingly engaged in for baseline security.

Consider our package delivery dock in the analogy above. In a sandboxed delivery system, the sender must first enter a sealed compartment and prove they’re actually carrying a box. If they fail, the compartment pushes them back out. If they succeed, they have to stick the box into another compartment that doesn’t close until it’s sure they’re out of it, at which point a robot X-rays the box, gently unpacks it, and so forth.

By design, sandboxed components and apps are unable to access files, input/output devices, or other resources outside their little play area. If malicious code causes one component to crash, it takes the sandbox with it, but it’s much less likely to affect anything else or produce a useful result that an attacker can use to infer details. No sandbox is perfect, and crackers try to break sandboxes too, not just the code running inside them. But abstracting and isolating actions increases the challenge substantially.

BlastDoor and other new messaging handling elements also have these improvements:

• Crash monitoring: The message system can tell when it crashes, which allows it to avoid leaking information about the crash to a malicious sender, and it reports the crash to Apple’s central iMessage servers. Senders get a delivery receipt in all cases, instead of only when the message doesn’t cause a crash.
• Obscuring where the message handler runs (iOS/iPadOS): A lot of exploits involve guessing where in physical memory legitimate code is operating to overwrite it with malicious code. A technique introduced in iOS 14/iPadOS 14 shifts that location around for shared cached data, making it effectively useless—even more so when paired with the previous fix, as an attacker can’t use the lack of a delivery receipt to determine if a crash occurred.
• Exponential throttling: When one of iMessage’s message-handling components starts to crash, a new feature automatically begins increasing the duration before iMessage relaunches the crashed component. So far, that’s just for iMessage, but it could be extended to other services. The longer it takes a cracker to cycle through brute force attacks, the less likely they will succeed and the more likely they will be noticed.

Finally, Samuel Groß notes that Apple has implemented—but left inactive—an additional safeguard to protect against a specific form of arbitrary code execution. He speculates that Apple is evaluating the performance impact of this change with the goal of turning it on in the future to further reduce the potential success of attacks.

All that said, you can build all the protections you want, and the bad guys will continue to try to break through them. Make a bomb big enough or focused enough, and it will punch through any blast door. But the idea here is to increase the cost of breaking in—if that bomb requires the resources of a nation-state, you can at least be certain that you’re safe from petty criminals. Plus, with iMessage’s new crash-reporting capabilities, Apple has a better chance of detecting and defending against new attacks.