Apple has made structural improvements in iOS 14 to block message-based, zero-click exploits.
In an effort to prevent attacks from being launched via its iMessage feature, Apple has debuted a security service called BlastDoor in iOS 14, its current mobile operating system version.
1st detailed in an analysis last week by Google Project Zero’s Samuel Groß, BlastDoor acts as a “tightly sandboxed” service that is responsible for “almost all” of the using of untrusted data in iMessages.
The service comes after a recently uncovered iMessage zero-click exploit, which was being leveraged in an espionage attack against Al Jazeera journalists and executives. Citizen Lab, who disclosed the campaign in Dec., at the time said it did not believe that the exploit works against iOS 14, as it “includes new security protections.”
However, what those specific protections were remained unknown until Groß’s analysis last week. Groß was able to perform reverse engineering in order to analyse the new service, using an M1 Mac Mini running macOS 11.1, & verifying his findings by applying them to iOS 14.3 (running on an iPhone XS),
“Overall, these changes are probably very close to the best that could’ve been done given the need for backwards compatibility, & they should have a significant impact on the security of iMessage & the platform as a whole,” said Groß last Thurs.
“It’s great to see Apple putting aside the resources for these kinds of large refactorings to improve end users’ security.”
What is BlastDoor?
BlastDoor has 2 important security implications.
1st, the service allows sandboxing rules to be applied across the pipeline when a message is received on a phone. This means that when a message is received, the processes on the backend execute code separately from the operating system. Only 2 processes (IMTransferAgent, which handles message file transfers, & apsd, Apple’s Push Notification Service daemon) are required to perform network operations.
Groß said the sandbox profile of BlashDoor is “quite tight,” with almost all file system interactions being blocked, outbound network access being denied, & any interaction with IOKit drivers being forbidden. IOKit allows the access of hardware devices & drivers for various apps & services & is historically a big source of vulnerabilities.
This secure environment means that any malicious code sent by attackers via iMessage is prevented from accessing user data or interacting with other parts of the operating system.
2nd, BlastDoor is written in Swift, which is a memory-safe language. Groß observed that Swift makes it “significantly” harder to introduce memory-corruption vulnerabilities into the code base. That’s because Swift has various features to make sure variables are initialised before they’re used, memory isn’t accessed after it’s been deallocated, & array indices are checked for out-of-bounds errors.
In earlier versions of iOS, when a message was sent, the parsing would occur in the Instant Messaging Agent (imagent). To parse a message in imagent, the binary data would 1st be decompressed; then the plist (also known as property list; an extension used to save preferences of applications) would be decoded from its binary serialisation format.
The various fields would be extracted to ensure they have the correct type; & finally, the `x` field content of the iMessage format would be decoded using an XML decoder. If an iMessage contained an attachment, additional steps would also be taken for parsing.
In iOS 14, this process has been moved to the new BlastDoor service. The main processing flow still begins in imagent – which receives the raw payload bytes, but then the messages are forwarded to the BlastDoor service (through +[IMBlastdoor sendDictionary:withCompletionBlock:]).
Within BlastDoor, the processes of both parsing messages & attachments mostly occur in BlastDoor.framework & MessagesBlastDoorService, commented Groß.
Groß noted that 1 side-effect of this new processing pipeline is that imagent can now detect when an incoming message caused a crash in BlastDoor – & appears to be informing Apple’s servers about such events.
“It is unclear what the purpose of this is without access to the server’s code,” commented Groß.
“While these notifications may simply be used for statistical purposes, they would also give Apple a fairly clear signal about attacks against iMessage involving brute-force & a somewhat weaker signal about any failed exploits against the BlastDoor service.”
Further to BlastDoor, Groß explained 2 other significant security protections that were built into iOS 14, which was released publicly in Sept.
1st, Apple has fixed an issue with the shared cache region of its address space layout randomisation (ASLR) that was posing an architectural weakness. The weakness related to the shared caches region only randomising per boot – meaning it would stay at the same address across all processes.
This could have allowed attackers to infer the base address of the shared cache & break ASLR – potentially setting them up to launch zero-click attacks.
Apple has now added logic to specifically detect this kind of attack. Now, shared cache is re-randomised for the targeted service during the next time it is started, rendering this type of attack ineffective.
“This should make bypassing ASLR in a 0-click attack context significantly harder or even impossible (apart from brute force) depending on the concrete vulnerability,” said Groß.
2nd, the BlastDoor & imagent services are now subject to a newly introduced “exponential throttling mechanism” enforced by launched, Apple’s operating system service management daemon.
With this new mechanism, if a crash occurs on the device, the intervals between restarts after the crash double with every subsequent crash (leading to an interval maxing out at 20 mins., Groß found).
“With this change, an exploit that relied on repeatedly crashing the attacked service would now likely require in the order of multiple hours to roughly half a day to complete instead of a few minutes,” said Groß.
Apple, historically known for its strong security posture, has faced various issues over the past few months – including the release of an emergency update this week to patch 3 zero-day vulnerabilities discovered in iOS.
Zero-click attacks run automatically without any user interaction are & of particular worry. Researchers last Aug. uncovered a zero-click macOS exploit chain that could allow attackers to deliver malware to macOS users using a Microsoft Office document with macros.
Groß applauded Apple’s offensive security work reflected in the recent changes, particularly for its impact against message-based zero-click attacks.
“Not just single bugs were fixed, but instead structural improvements were made based on insights gained from exploit development work,” he concluded.