Jamf Blog
Hand clicking on an Apple Magic Mouse
April 20, 2020 by Jamf Threat Labs

You’ve got (0-click) mail!

Jamf identifies zero-click threats that target vulnerable iOS devices, compromising them through the Mail app. Read more about this threat and how to protect your Apple mobile fleet against it effectively.

Updates

  • The vulnerability affected even the first iPhone (iPhone 1 or iPhone 2G) on iOS 3.1.3
  • First "in-the-wild" trigger to this vulnerability happened on October 2010
  • As you can see in the new writeup, this vulnerability is exploitable and we encourage releasing a patch as soon as possible
  • We launched a bounty program for attacks related to MailDemon
  • The IOCs & FAQ were updated

Impact & Key Details (TL;DR)

  • The vulnerability allows remote code execution capabilities and enables an attacker to remotely infect a device by sending emails that consume a significant amount of memory
  • The vulnerability does not necessarily require a large email – a regular email that is able to consume enough RAM would be sufficient. There are many ways to achieve such resource exhaustion including RTF, multi-part and other methods
  • Both vulnerabilities were triggered in-the-wild
  • The vulnerability can be triggered before the entire email is downloaded, hence the email content won’t necessarily remain on the device
  • We are not dismissing the possibility that attackers may have deleted any remaining emails following a successful attack
  • Vulnerability trigger on iOS 13: Unassisted (zero-click) attacks on iOS 13 when the Mail application is open in the background
  • Vulnerability trigger on iOS 12: The attack requires a click on the email. The attack will be triggered before rendering the content. The user won’t notice anything anomalous in the email itself
  • Unassisted attacks on iOS 12 can be triggered (aka zero-click) if the attacker controls the mail server
  • The vulnerabilities have existed since at least iOS 6 – (issue date: September 2012) – when iPhone 5 was released
  • The earliest triggers we have observed in the wild were on iOS 11.2.2 in January 2018
  • FAQ
Infographic on vulnerability lifecycle

Multiple Vulnerabilities in MobileMail/Maild

Introduction

Following a routine iOS Digital Forensics and Incident Response (DFIR) investigation, Jamf found a number of suspicious events that affected the default Mail application on iOS dating as far back as Jan 2018. Jamf analyzed these events and discovered an exploitable vulnerability affecting Apple’s iPhones and iPads. Jamf detected multiple triggers in the wild to this vulnerability on enterprise users, VIPs, and MSSPs, over a prolonged period of time.

The attack’s scope consists of sending a specially crafted email to a victim’s mailbox enabling it to trigger the vulnerability in the context of iOS MobileMail application on iOS 12 or maild on iOS 13. Based on intelligence gathered by Jamf Threat Labs, we surmise with high confidence that these vulnerabilities – in particular, the remote heap overflow – are widely exploited in the wild in targeted attacks by advanced threat operator(s).

The suspected targets included:

  • Individuals from a Fortune 500 organization in North America
  • An executive from a carrier in Japan
  • A VIP from Germany
  • MSSPs from Saudi Arabia and Israel
  • A Journalist in Europe
  • An executive from a Swiss enterprise

A few of the suspicious events even included strings commonly used by hackers (e.g. 414141…4141) – see FAQ. After verifying that it wasn’t a red-team exercise, we validated that these strings were provided by the email-sender. Noteworthy, although the data confirms that the exploit emails were received and processed by victims’ iOS devices, corresponding emails that should have been received and stored on the mail-server were missing. Therefore, we infer that these emails may have been deleted intentionally as part of attack’s operational security cleanup measures.

We believe that these attacks are correlative with at least one nation-state threat operator or a nation-state that purchased the exploit from a third-party researcher in a Proof of Concept (POC) grade and used ‘as-is’ or with minor modifications (hence the 4141..41 strings).

While Jamf refrains from attributing these attacks to a specific threat actor, we are aware that at least one "hackers-for-hire" organization is selling exploits using vulnerabilities that leverage email addresses as a main identifier.

We advise to update as soon as an iOS update is available.

Exploitation timeline

We are aware of multiple triggers in the wild that happened starting from Jan 2018, on iOS 11.2.2. It is likely that the same threat operators are actively abusing these vulnerabilities presently. It is possible that the attacker(s) were using this vulnerability even earlier. We have seen similarities between some of the suspected victims during triggers to these vulnerabilities.

Affected versions:

  • All tested iOS versions are vulnerable including iOS 13.4.1
  • Based on our data, these bugs were actively triggered on iOS 11.2.2 and potentially earlier
  • iOS 6 and above are vulnerable. iOS 6 was released in 2012. Versions prior to iOS 6 might be vulnerable too but we haven’t checked earlier versions. At the time of iOS 6 release, iPhone 5 was in the market

Jamf Customers & Partners

Jamf customers can detect attacks leveraging MobileMail/maild vulnerabilities.

Thank you

Before we dive deeper, we would like to thank Apple’s product security and engineering teams that delivered a beta patch to block these vulnerabilities from further abuse once deployed to GA.

Vulnerability Details

Jamf found that the implementation of MFMutableData in the MIME library lacks error checking for system call ftruncate() which leads to the Out-Of-Bounds write. We also found a way to trigger the OOB-Write without waiting for the failure of the system call ftruncate. In addition, we found a heap-overflow that can be triggered remotely.

We are aware of remote triggers of both vulnerabilities in the wild.

Both the OOB Write bug, and the Heap-Overflow bug, occurred due to the same problem: not handling the return value of the system calls correctly.

The remote bug can be triggered while processing the downloaded email, in such scenario, the email won’t get fully downloaded to the device as a result.

Affected Library: /System/Library/PrivateFrameworks/MIME.framework/MIME

Vulnerable function: -[MFMutableData appendBytes:length:]

Abnormal behavior once the vulnerabilities are exploited

Besides a temporary slowdown of mobile mail application, users should not observe any other anomalous behavior. Following an exploit attempt (both successful/unsuccessful) on iOS 12 – users may notice a sudden crash of the Mail application.

On iOS13, besides a temporary slowdown, it would not be noticeable. Failed attacks would not be noticeable on iOS 13 if another attack is carried afterwards and deletes the email.

In failed attacks, the emails that would be sent by the attacker would show the message: “This message has no content.”, as seen in the following picture below:

Screenshot of zero-click email received in Mail

Crash Forensics Analysis

Part of the a crash (out of multiple crashes) experienced by the user, is as follows.

The crashed instruction was stnp x8, x9, [x3], meaning that the value of x8 and x9 has been written into x3 and crashed due to accessing an invalid address 0x000000013aa1c000 which was stored in x3.

In order to find out why the process crashed, we need to take a look at the implementation of MFMutableData.

The below call tree is taken from the crash log experienced only by a selected number of devices.

By analyzing the MIME library, the pseudo-code of -[MFMutableData appendBytes:length:] as follows:

The following call stack was executed before the crash happened:

A file is used to store the actual data if the data size reaches the threshold, when the data changes, the content and the size of the mapped file should be changed accordingly. The system-call ftruncate() is called inside -[MFMutableData _flushToDisk:capacity:] to adjust the size of the mapped file.

Following is the pseudo code of -[MFMutableData _flushToDisk:capacity:]

The man page of ftruncate specifies:

According to the man page: “If the call fails a -1 is returned, and the global variable errno specifies the error.” which means under certain conditions, this system call would fail to truncate the file and return an error code.

However, upon failure of the ftruncate system call , _flushToDisk continues anyway, which means the mapped file size is not extended and the execution finally reaches the memmove() in the appendBytes() function, causing the mmap file an out-of-bound (OOB) write.

Finding another trigger

We know that the crash was due to a failure ftruncate() system call, does it mean we can’t do anything but wait for the system call to fail?

Let’s take another look at the -[MFMutableData _flushToDisk:capacity:] function.

As you can see in line [b], it checks whether the flush flag is true before calling ftruncate(). This means if we can set the flush flag to false at line [a], the ftruncate() won’t be executed at all.

If someone calls -[MFMutableData setLength:](set flush to 0), before calling -[MFMutableData appendData:], ftruncate() won’t be executed due to flush==0) and there will be a similar result.

The following backtrace is a demonstration of a local POC. Combining this OOB Write with an additional vulnerability and/or methods to control the memory layout, this vulnerability could be triggered remotely – for example by controlling the selectors (as we have observed in other DFIR events as well as in Google Project Zero blog post).

Although this is indeed a vulnerability that should be patched, we suspect that it was triggered by accident while the attackers were trying to exploit the following vulnerability.

2nd Vulnerability: Remote Heap Overflow in MFMutable

We continued our investigation into the remotely triggered events that were suspicious and determined that there is another vulnerability in the same area

The backtrace can be seen as follows:

While analyzing the code flow, we determined the following:

  • The function [MFDAMessageContentConsumer consumeData:length:format:mailMessage:] gets called when downloading an email in raw MIME form, and also will get called multiple times until the email is downloaded in Exchange mode. It will create a new NSMutableData object, and call appendData: for any new streaming data that belongs to the same email/MIME message. For other protocols like IMAP it uses -[MFConnection readLineIntoData:] instead but the logic and vulnerability are the same.
  • NSMutableData sets a threshold of 0x200000 bytes, if the data is bigger than 0x200000 bytes, it will write the data into a file, and then use the mmap system call to map the file into the device memory. The threshold size of 0x200000 can be easily excessed, so every time new data needs to append, the file will be re-mmap’ed, and the file size, as well as the mmap size, gets bigger and bigger.
  • Remapping is done inside -[MFMutableData _mapMutableData:], the vulnerability is inside this function.

Pseudocode of the vulnerable function as below:

-[MFMutableData _mapMutableData:] calls function MFMutableData__mapMutableData___block_invoke when the mmap system call fails

The pseudo-code of MFMutableData__mapMutableData___block_invoke is as follows, it allocates a size 8 heap memory then replaces the data->bytes pointer with the allocated memory.

After the execution of -[MFMutableData _mapMutableData:], the process continues the execution of -[MFMutableData appendBytes:length:], causing a heap overflow when copying data to the allocated memory.

append_length is the length of a chunk of data from the streaming. Since MALLOC_NANO is a very predictable memory region, it is possible to exploit this vulnerability.

An attacker doesn’t need to drain every last bit of the memory to cause mmap to fail, as mmap requires a continuous memory region.

Reproduction

According to the man page of mmap, the mmap would fail when MAP_ANON was specified and insufficient memory was available.

The goal is to cause mmap to fail, ideally, a big enough email is going to make it happen inevitably. However, we believe that the vulnerabilities can be triggered by using other tricks that can exhaust the resources. Such tricks can be achieved through multi-part, RTF, and other formats – more on that later.

Another important factor that can affect exploitability, is the hardware specs:

  • iPhone 6 has 1GB
  • iPhone 7 has 2GB
  • iPhone X has 3GB

For older devices with smaller physical RAM and smaller virtual memory space, hence it is not necessary to drain every last bit of RAM in order to trigger this bug, mmap will fail when it cannot find a continuous memory of a given size in the available virtual memory space.

We have determined that MacOS is not vulnerable to both vulnerabilities.

In iOS 12, it is easier to trigger the vulnerability because the data streaming is done within the same process, as the default mail application (MobileMail), it deals with much more resources, which eats up the allocation of virtual memory space, especially the UI rendering, whereas in iOS 13, MobileMail pass data streaming to a background process namely maild. It concentrates its resources on parsing emails, which reduces the risk of virtual memory space accidentally running out.

Remote Reproduction / POC

Since MobileMail/maild didn’t explicitly set the max limit for email size, it is possible to set up a custom email server and send an email that has several GB of plain text. iOS MIME/Message library chunks data into an average of roughly 0x100000 bytes while streaming data, so failing to download the entire email is totally fine.

Please note that this is just one example of how to trigger this vulnerability. Attackers do not need to send such an email to trigger this vulnerability, and other tricks with multi-part, RTF, or other formats may accomplish the same objective with a standard-size email.

Screenshot of the Indicators of Compromise list

Patch

Apple patched both vulnerabilities in iOS 13.4.5 beta, as can be seen in the following screenshot below:

Screenshot of patch code

To mitigate these issues – you can use the latest beta available. If using a beta version is not possible, consider disabling the Mail application and using Outlook, Edison Mail or Gmail which are not vulnerable.

Disclosure timeline

  • February 19th, 2020 – Suspected events reported to the vendor under Jamf's responsible disclosure policy which allows immediate release for in-the-wild triggers
  • Ongoing communication between the affected vendor & Jamf
  • March 23rd – Jamf sent to the affected vendor a POC reproduction of the OOB Write vulnerability
  • March 25th – Jamf shared a local POC for the OOB Write
  • March 31st – Jamf confirmed a second vulnerability exists in the same area and the ability of a remote trigger(Remote Heap Overflow) – both vulnerabilities were triggered in the wild
  • March 31st – Jamf shared a POC with the affected vendor for the remote heap-overflow vulnerability
  • April 7th – Jamf shared a custom Mail Server to trigger the 0-click heap overflow vulnerability on iOS 13.4 / 13.4.1 easily by simply adding the username & password to Mail and downloading the emails
  • April 15/16th – Vendor patches both vulnerabilities in the publicly available beta
  • April 20th – We re-analyzed historical data and found additional evidence of triggers in the wild on VIPs and targeted personas. We sent an email notifying the vendor that we will have to release this threat advisory imminently in order to enable organizations to safeguard themselves as attacker(s) will likely increase their activity significantly now that it’s patched in the beta
  • April 22nd – Public disclosure

FAQ

Q: Was the first and/or the second vulnerability exploited in the wild?

A: The suspected emails triggered code paths of both vulnerabilities in the wild, however, we think the first vulnerability (OOB Write) was triggered accidentally, and the main goal was to trigger the second vulnerability (Remote Heap Overflow).

  1. We have seen multiple triggers on the same users across multiple continents.
  2. We examined the suspicious strings & root cause (such as the 414141…41 events and most other events):
    • We confirmed that this code path does not get randomly triggered.
    • We confirmed the values of the registers did not originate from the targeted software or from the operating system.
    • We confirmed it was not a red team exercise/POC test.
    • We confirmed that the controlled pointers containing 414141…41, as well as other controlled memory, were part of the data sent via email to the victim’s device.
  3. We verified that the bugs were remotely exploitable & reproduced the trigger.
  4. We saw similarities between the patterns used against at least a couple of the victims sent by the same attacker.
  5. Where possible, we confirmed that the allocation size was intentional.
  6. Lastly, we verified that the suspicious emails were received and processed by the device – according to the stack trace and it should have been on the device/mail server. Where possible, together with the victims, we verified that the emails were deleted.

Based on the above, together with other information, we surmise that these vulnerabilities were actively exploited in the wild.

Q: Does an attacker have to trigger the first vulnerability first in order to trigger the second one?

A: No. An attacker would likely target the second vulnerability.

Q: Why are you disclosing these bugs before a full patch is available?

A: It’s important to understand the following:

  • These bugs alone cannot cause harm to iOS users – since the attackers would require an additional infoleak bug & a kernel bug afterward for full control over the targeted device.
  • Both bugs were already disclosed during the publicly available beta update. The attackers are already aware that the golden opportunity with MobileMail/maild is almost over and they will likely use the time until a patch is available to attack as many devices as possible.
  • With very limited data we were able to see that at least six organizations were impacted by this vulnerability – and the potential abuse of this vulnerability is enormous. We are confident that a patch must be provided for such issues with public triggers ASAP.

It is our obligation to the public, our customers, partners, and iOS users globally to disclose these issues so people who are interested can protect themselves by applying the beta patch, or stop to use Mail and temporarily switch to alternatives that are not vulnerable to these bugs.

We hope that with making this information public it will help to promote a faster patch.

Q: Can both vulnerabilities be triggered remotely?

A; The remote heap overflow has been proven to be possible to trigger remotely without any user interaction (0-click) on iOS13. The OOB write can be triggered remotely with an additional vulnerability that allows calling an arbitrary selector, just like the one published by Google Project Zero. Since we saw an in-the-wild trigger for the first vulnerability, it is possible, although we think it was done by mistake (see above).

Q: Do end users require to perform any action for the exploitation to succeed?

A: On iOS 13: no. On iOS 12: it requires the victim to click on an email.

If an attacker controls the mail server, the attack can be performed without any clicks on iOS 12 too.

Q: Since when iOS is vulnerable to these bugs?

A: iOS is vulnerable to these bugs at least since iOS 6 (Sept 2012). We haven’t checked earlier versions.

Q: What can you do to mitigate the vulnerability:

A: The newly released beta update of 13.4.5 contains a patch for these vulnerabilities. If you cannot patch to this version instead of using the Mail application consider using other mail applications until a GA patch is available.

Q: Does an attacker need to send a very large email (e.g. 1-3 GB) to trigger the vulnerability?

A: No. Attackers may use tricks in multi-part / RTF, etc in order to consume the memory in a similar way without sending a large email.

Q: Does the vulnerability require additional information to succeed?

A: Yes, an attacker would need to leak an address from the memory in order to bypass ASLR. We did not focus on this vulnerability in our research.

Q: What does the vulnerability allow:

A: The vulnerability allows running remote code in the context of MobileMail (iOS 12) or maild (iOS 13). Successful exploitation of this vulnerability would allow the attacker to leak, modify, and delete emails. Additional kernel vulnerability would provide full device access – we suspect that these attackers had another vulnerability. It is currently under investigation.

Q: Would end users notice any abnormal behavior once either vulnerability are triggered/exploited?

A: Besides a temporary slowdown of mobile mail application, users should not observe any other anomalous behavior.

When the exploit fails on iOS 12, users may notice a sudden crash of the Mail application.

On iOS13, besides a temporary slowdown, it would not be noticeable. Failed attacks would not be noticeable on iOS 13 if another attack is carried out afterward and deletes the email. In failed attacks, the emails that would be sent by the attacker would show the message: "This message has no content." As displayed in the picture above (see Abnormal behavior once the vulnerabilities are exploited section).

Q: if the attackers fail, can they re-try to attack using the same vulnerability right after?

A: On iOS 13, attackers may try multiple times to infect the device silently and without user interaction. On iOS 12, an additional attempt would require the user to click on a newly received email by the attackers. The victim does not need to open an attachment and just viewing the email is sufficient to trigger the attack.

Q: Can the attackers delete the received email after it was processed by the device and triggered the vulnerability?

A: Yes

Q; Is MacOS vulnerable to these vulnerabilities too?

A: No

Jamf protects against this and numerous other security threats impacting your enterprise fleet.

Jamf Threat Labs
Jamf
Jamf Threat Labs is a global team of experienced threat researchers, cybersecurity experts and data scientists with skills that span penetration testing, network monitoring, malware research and app risk assessment. Jamf Threat Labs primarily monitors and explores emerging threats affecting Mac and mobile devices. The team’s research is published with the aim of raising awareness of specific threats while also improving awareness and advocacy of security practices to protect the modern workforce.
Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.

To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.