After being hit by a 0-click exploit in iMessage last year, Apple has been hard at work to improve the security of its platform, writes Google security researcher Samuel Groß. One of the major changes in iOS 14 is BlastDoor, a tightly sandboxed service responsible for parsing all untrusted messages, along with better randomization of the shared cache region containing all system libraries, and the use of exponential throttling to counter brute-force attacks.
According to Groß, the new iMessage pipeline includes more than seven different services involved in message processing,
The majority of the processing of complex, untrusted data has been moved into the new BlastDoor service. Furthermore, this design with its 7+ involved services allows fine-grained sandboxing rules to be applied.
This enables BlastDoor to use a very strict set of rules, while other services have looser rules. BlastDoor's rules only enable access to a handful of services, including diagnosticd, logd,opendirectoryd, syslogd, and notifyd. They also strongly restrict file system interaciont and completely forbid outbound network access and interaction with drivers.
Interestingly, each time BlastDoor crashes, some Apple servers appear to be notified. Groß says that without accessing the server's code, it is hard to say how that information is used. On the one hand, it could provide a warning that some attacks against iMessage may be taking place. On the other, it seems to be related to an attempt to confuse the attacker:
In my experiments, after observing one of these crash notifications, the server would start directly sending delivery receipts to the sender for messages that hadn't actually been processed by the receiver yet. Possibly this is another, independent effort to break the crash oracle technique by confusing the sender [...]
Groß also stressed the importance of using Swift to write BlastDoor. In fact, Swift's safety guarantees reduce the chance of introducing memory corruption vulnerabilities, which are often exploited to gain control of a system, but BlastDoor is still relying on older code written in Objective-C for XML parsing with libxml and payload decryption through NSKeyedUnarchiver.
BlastDoor, sandboxing, and crash monitoring are not the only ways Apple has hardened iMessage. As mentioned, Apple also worked to fix one of the architectural weaknesses of its platform, the shared cache region.
The shared cache region, containing most of the system libraries in a single prelinked blob, was only randomized per boot, and so would stay at the same address across all processes.
This used to make it easier for an attacker to infer the base address of the shared cache an break address space layout randomization. Apple's fix for this has been creating a kernel-based mechanism to assign an attacked service a new reslided shared cache image after a crash is detected.
The final provision to make iMessage more secure is exponential throttling, which is aimed at limiting attempts to tamper with a service and protecting against brute-force attacks. In this case, when a crash is detected, if the crashed service has _ExponentialThrottling enabled in its launchd .plist file, its restart is delayed by an exponentially increasing time. This goes up to a maximum of 20 minutes, according to Groß's experimental findings. As with shared cache image resliding, this is a platform-wide feature, although it seems to be currently used only for the BlastDoor service.
Groß's article is rich in interesting technical details about the new iMessage pipeline and the new security-related features of iOS and macOS, so you may want to make sure you read it to get the full picture.
