Zero click vulnerability in Apple’s macOS Mail

4 min readApr 1, 2021

Zero-Click Zip TL;DR

I found a zero click vulnerability in Apple Mail, which allowed me to add or modify any arbitrary file inside Mail’s sandbox environment. This could lead to many bad things including unauthorized disclosure of sensitive information to a third party. An attacker can modify victim’s Mail configuration including mail redirects which enables takeover of victim’s other accounts via password resets. This vulnerability can be used to change the victim’s configuration so that victims will be propagating the attack to their correspondents in a worm-like fashion. Apple has patched this vulnerability in 2020–07.

Story

I was researching another vulnerability case (I’ll write about it a bit later) when I found this. I was reading Apple’s Bug Bounty categories and started to think what attack vectors there might be to trigger without user action. First idea obviously was Safari. I played a bit with Safari but couldn’t find any interesting leads. Next thing on my mind was Mail or iMessage. I focused on the Mail because of the hunch about the legacy features hiding in older codebase. I started to play around with Mail, sending test messages and attachments with the idea of trying to find an anomaly compared to normal email sending and receiving. I sent these test messages and followed Mail process syscalls to learn what is happening under the hood when email is received and here is what I found.

Technical details

Description

Mail has a feature which enables it to automatically uncompress attachments which have been automatically compressed by another Mail user.

In the valid use case, if the user creates email and adds the folder as an attachment it will be automatically compressed with zip and x-mac-auto-archive=yes; is added to the MIME headers. When another Mail user receives this email, compressed attachment data is automatically uncompressed.

During my research I found that parts of the uncompressed data is not cleaned from temporary directory and that directory is not unique in context of Mail, this can be leveraged to get unauthorized write access to ~/Library/Mail and to $TMPDIR using symlinks inside of those zipped files.

Here is what happens

Attacker sends an email exploit which includes two zip files as attachments to the victim. Immediately when the user receives the email, Mail will parse it to find out any attachments with x-mac-auto-archive=yes header in place. Mail will uncompress those files automatically.

1st stage

First zip includes a symlink named Mail which points to victims “$HOME/Library/Mail” and file 1.txt . Zip gets uncompressed to “$TMPDIR/com.apple.mail/bom/”. Based on “filename=1.txt.zip” header, 1.txt gets copied to mail dir and everything works as expected. However cleanup is not done right way and the symlink is left in place.

2nd stage

Second attached zip includes the changes that you want to do to “$HOME/Library/Mail”. This will provide arbitrary file write permission to Library/Mail.

In my example case I wrote new Mail rules for the Mail application. With that you can add an auto forward rule to the victim’s Mail application.

Mail/ZCZPoC
Mail/V7/MailData/RulesActiveState.plist
Mail/V7/MailData/SyncedRules.plist

Mail/ZCZPoC includes just a plaintext file which will be written to ~/Library/Mail.

Overwrite Mail rule list

Files can be overwritten and that is what happens with the RulesActiveState.plist and the SyncedRules.plist files.

Main thing in the RulesActiveState.plist is to activate our rule in the SyncedRules.plist.

…
<dict>
<key>0C8B9B35–2F89–418F-913F-A6F5E0C8F445</key>
<true/>
</dict>
…

SyncedRules.plist contains a rule to match “AnyMessage” and rule in this PoC sets Mail application to play morse sound when any message is received.

…
<key>Criteria</key>
<array>
<dict>
<key>CriterionUniqueId</key>
<string>0C8B9B35–2F89–418F-913F-A6F5E0C8F445</string>
<key>Header</key>
<string>AnyMessage</string>
</dict>
</array>
…
<key>SoundName</key>
<string>Morse</string>

Instead of playing morse sound, this could be e.g forwarding rule to leak sensitive email data.

Impact

This arbitrary write access allows the attacker to manipulate all of the files in $HOME/Library/Mail. As shown this will lead to exposure of the sensitive data to a third party through manipulating the Mail application’s configuration. One of the available configuration options is the user’s signature which could be used to make this vulnerability wormable.

There is also a chance that this could lead to a remote code execution (RCE) vulnerability, but I didn’t go that far.

Timeline

2020–05–16: Issue found

2020–05–24: PoC done and reported to Apple

2020–06–04: Catalina 10.15.6 Beta 4 with Hotfix relased

2020–07–15: macOS Mojave 10.14.6, macOS High Sierra 10.13.6, macOS Catalina 10.15.5 Update with hotfix released

2020–11–12: Credits released (CVE-2020–9922)

2021–03–30: Bug Bounty is still being evaluated

2021–04–16: Apple qualifies report for the Apple Security Bounty

2021–04–29: Apple paid the bounty

Thanks to the fellow researchers who have shared their findings and knowledge, and thanks to Apple for the quick fixes. Huge thanks to my colleagues who helped me with this writeup! :)