Apple BlastDoor sandboxApple BlastDoor sandbox

Google Project Zero on Thursday disclosed details of a new
security mechanism that Apple quietly added to iOS 14 as a
countermeasure to prevent attacks that were recently found to
leverage zero-days in its messaging app.

Dubbed “BlastDoor,” the improved sandbox system for
iMessage data was disclosed by Samuel Groß, a security researcher
with Project Zero, a team of security researchers at Google tasked
with studying zero-day vulnerabilities in hardware and software
systems.

“One of the major changes in iOS 14 is the introduction of a
new, tightly sandboxed ‘BlastDoor’ service which is now responsible
for almost all parsing of untrusted data in iMessages,” Groß
said[1]. “Furthermore, this
service is written in Swift, a (mostly) memory safe language which
makes it significantly harder to introduce classic memory
corruption vulnerabilities into the code base.”

password auditor

The development is a consequence of a zero-click exploit[2]
that leveraged an Apple iMessage flaw in iOS 13.5.1 to get around
security protections as part of a cyberespionage campaign targeting
Al Jazeera journalists last year.

“We do not believe that [the exploit] works against iOS 14 and
above, which includes new security protections,” Citizen Lab
researchers who revealed the attack last month.

BlastDoor forms the core of those new security protections, per
Groß, who analyzed the implemented changes over the course of a
week-long reverse engineering project using an M1 Mac Mini running
macOS 11.1 and an iPhone XS running iOS 14.3.

When an incoming iMessage arrives, the message passes through[3]
a number of services, chief among them being the Apple Push
Notification Service daemon (apsd) and a background process called
imagent, which is not only responsible for decoding the message
contents but also for downloading attachments (through a separate
service called IMTransferAgent) and handling links to websites,
before alerting the SpringBoard[4]
to display the notification.

Apple BlastDoor sandboxApple BlastDoor sandbox

What BlastDoor does is inspect all such inbound messages in a
secure, sandboxed environment, which prevents any malicious code
inside of a message from interacting with the rest of the operating
system or accessing user data.

Put differently, by moving a majority of the processing tasks —
i.e., decoding the message property list and creating link previews
— from imagent to this new BlastDoor component, a specially-crafted
message sent to a target can no longer interact with the file
system or perform network operations.

“The sandbox profile is quite tight,” Groß noted. “Only a
handful of local IPC[5]
services can be reached, almost all file system interaction is
blocked, any interaction with IOKit[6]
drivers is forbidden, [and] outbound network access is denied.”

What’s more, in a bid to delay subsequent restarts of a crashing
service, Apple has also introduced a new throttling feature in the
iOS “launchd[7]” process to limit the
number of tries an attacker gets when seeking to exploit a flaw by
exponentially increasing the time between two successive
brute-force attempts.

“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,” Groß said.

“Overall, these changes are probably very close to the best that
could’ve been done given the need for backwards compatibility, and
they should have a significant impact on the security of iMessage
and the platform as a whole.”

References

  1. ^
    said
    (googleprojectzero.blogspot.com)
  2. ^
    zero-click exploit
    (thehackernews.com)
  3. ^
    passes
    through
    (googleprojectzero.blogspot.com)
  4. ^
    SpringBoard
    (en.wikipedia.org)
  5. ^
    IPC
    (en.wikipedia.org)
  6. ^
    IOKit
    (developer.apple.com)
  7. ^
    launchd
    (en.wikipedia.org)

Read more