【更新】

本周四，苹果在一份声明中对前一日ZecOps公布的苹果“八年0dy漏洞”做出回应，否认了漏洞情况的严重性。

彭博社Mark Gurman收到相关声明后在推特分享了苹果公司的这一官方回应：

苹果严肃对待所有安全威胁的相关报告。我们已对研究人员的报告进行了仔细的调查。

根据调查结果发现，这些漏洞问题不会对用户造成直接风险。

研究人员确定了Mail中的三个漏洞问题，但仅凭它们不足以绕过iPhone和iPad的安全保护，而且我们还没有发现它们被用来攻击客户的证据。

声明最后苹果还表示，漏洞补丁即将发布。该公司通常会在每个软件版本中发布安全更新，以详细说明已修复的漏洞并感谢发现这些漏洞的安全研究人员或研究小组。

近日，安全研究人员发现iPhone和iPad自带的默认邮件应用程序MobileMail 和Maild存在两个正在被在野利用的严重漏洞，而且至少在两年前就已经开始监视用户了。

这两个漏洞允许远程攻击者秘密获取苹果设备的控制权，只要向已经登录邮件账号的用户设备发送电子邮件即可。这可能会使超过5亿部iPhone容易受到黑客的攻击。同时，iPad也存在这一问题。

旧金山的一家手机安全取证公司ZecOps在周三发布的一份报告中表示，在2019年末调查一起客户网络攻击事件时，发现了该问题。ZecOps创始人Zuk Avraham表示，他发现证据显示，这一漏洞至少在六起网络入侵事件中被利用。

Zuk推特声明

该漏洞是存在于苹果自带邮件应用程序中的MIME库中的远程代码执行漏洞，首先是因为越界写入错误，其次是堆溢出问题。

尽管两个电子邮件都是在处理邮件时触发的，但是第二个漏洞更为严重一些，因为其可以实现“零点击”利用，无需任何用户交互。

iOS 13上的漏洞触发：在后台打开Mail应用程序时，iOS 13上的无辅助（零点击）攻击；

iOS 12上的漏洞触发：攻击需要单击电子邮件，攻击将在呈现内容之前触发，用户不会在电子邮件本身中发现任何异常；

如果攻击者控制邮件服务器，则可以触发（即零点击）iOS 12上的无辅助攻击。

报告中还提及疑似遭受攻击的目标：

来自北美财富500强企业的员工；

日本某航空公司的高管 ；

来自德国的贵宾；

来自沙特阿拉伯和以色列的MSSP；

欧洲记者；

怀疑：一家瑞士企业的高管。

八年零日漏洞在野利用

据研究员表明，两个漏洞存在iPhone 和iPad多个版本中长达8年，可以追溯到iOS6，甚至影响了当前的iOS 13.4.1，常规版本尚且没有补丁更新。

更让人担忧的是，多个攻击者组织长期利用这些漏洞（至少在野零日攻击中利用了2年最早可追溯到2018年1月）。

研究人员说：“目前公布的攻击数据有限，但是至少有6个组织或者个体遭受攻击，影响力还是很大的。尽管ZecOps没有发现攻击的幕后黑手，但是我们了解到至少有一个“雇佣组织”在销售该漏洞利用，并将电子邮件地址作为唯一标识符。

此外，对于苹果用户本身来说是很难意识到黑客的入侵的，因为他们在获取用户远程操控之后，可以立即删除恶意电子邮件。

尽管数据表示是用户的iOS设备接收和处理电子邮件的，但是本应存储在邮件服务器上的邮件却消失了，因此可以推断故意删除是攻击手段的一部分。

除了邮件使用速度的短暂下降以外，用户没法发现任何的异常行为。成功的漏洞利用是让黑客在MobileMail 或者Maild 应用程序中执行恶意代码，并窃取、修改或者删除邮件。

然而，想要完全操控设备，黑客还需要一个助手，即单独的内核漏洞（比如无法修补的Checkm8漏洞）。尽管目前研究人员还没有发现黑客使用的恶意软件细节，但是邮件的漏洞和内核漏洞结合使用来监控他们的目标用户也不是没有可能。

当心！目前尚无可用补丁

研究人员在两个月前发现这次的在野利用攻击，并将其报告给苹果安全团队。

截至发文，只有iOS13.4.5 beta版本在上周发布，包含了这两个漏洞的安全补丁。

而数百外的iPhone 和iPad用户还需等待下一次的软件安全补丁更新。与此同时，强烈建议苹果用户不要使用设备内置的邮件应用程序。

漏洞详情

ZecOps发现，在MIME库中的执行MFMutableData，没有对系统调用ftruncate()进行错误检查，这会导致越界写入。研究人员找到了一种无需等待系统调用ftruncate失败即可触发OOB-Write的方法。此外，他们还发现可以远程触发的堆溢出。

事实上，这两种漏洞都是远程触发的。 OOB写入错误和堆溢出错误都是由于相同的问题而发生的：未正确处理系统调用的返回值。

远程错误可以在处理下载电子邮件时触发，在这种情况下，电子邮件将无法完全下载到设备上。

受影响的库：/System/Library/PrivateFrameworks/MIME.framework/MIME

漏洞功能：-[MFMutableData appendBytes:length:]

事故取证分析

用户经历的部分崩溃（多次崩溃中的一部分）如下。

崩溃指令是stnp x8, x9, [x3]，这意味着价值x8，并x9已写入x3并坠毁由于访问无效的地址0x000000013aa1c000，其存储在x3。

Thread 3 Crashed:
0   libsystem_platform.dylib          0x000000019e671d88 _platform_memmove +88
       0x19e671d84         b.ls 0x00008da8                
       0x19e671d88         stnp x8, x9, [x3]              
       0x19e671d8c         stnp x10, x11, [x3, #16]       
       0x19e671d90         add x3, x3, 0x20               
       0x19e671d94         ldnp x8, x9, [x1]              
1   MIME                              0x00000001b034c4d8 -[MFMutableData appendBytes:length:] + 356 
2   Message                           0x00000001b0b379c8 -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] + 808

为了找出导致流程崩溃的原因，来看一下MFMutableData的实现。

下面的调用树取自部分崩溃日志。

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] 
|
+--  -[MFMutableData appendData:]
   |
   +--  -[MFMutableData appendBytes:length:]
       |
       +-- memmove()

通过分析MIME库， -[MFMutableData appendBytes:length:] 伪代码如下：

崩溃发生之前，已执行以下调用堆栈：

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] 
|
+--  -[MFMutableData appendData:]
   |
   +--  -[MFMutableData appendBytes:length:]
       |
       +-- -[MFMutableData setLength:]
          |
          +-- -[MFMutableData _flushToDisk:capacity:]
             |
             +-- ftruncate()

如果数据大小达到阈值，则使用文件来存储实际数据，当数据更改时，应相应更改映射文件的内容和大小。-[MFMutableData _flushToDisk:capacity:]在内部调用系统调用ftruncate()来调整映射文件的大小。

以下是-[MFMutableData _flushToDisk:capacity:] 的伪代码：

ftruncate详情主页：

ftruncate() and truncate() cause the file named by path, or referenced by fildes, to be truncated
 (or extended) to length bytes in size. If the file size exceeds length, any extra data is discarded. 
If the file size is smaller than length, the file is extended and filled with zeros to the indicated 
length.  The ftruncate() form requires the file to be open for writing.
RETURN VALUES
    A value of 0 is returned if the call succeeds.  If the call fails a -1 is returned, and the global 
    variable errno specifies the error.

主页显示：“If the call fails a -1 is returned, and the global variable errno specifies the error.”这意味着在某些情况下，此系统调用将无法截断文件并返回错误代码。

然而，一旦系统调用ftruncate失败，无论如何_flushToDisk会继续进行，这意味着在appendBytes()函数中映射文件大小没有延伸并无法执行达到memmove()，这导致MMAP文件的OOB写入。

寻找另一个触发因素

崩溃是由于系统调用ftruncate()失败引起的，是否意味着除了等待系统调用失败之外什么也不能做？

再来看一下-[MFMutableData _flushToDisk:capacity:]函数。

在[b]行中所见，检查flush在调用ftruncate()之前标志是否为true。这意味着，如果可以将flush在第[a]行将标志设置为false ，则ftruncate()根本不会执行。

如果有人在调用-[MFMutableData appendData:]之前调用-[MFMutableData setLength:](set flush to  0), ftruncate() won’t be executed due to flush==0)，将会得到类似的结果。

将此OOB Write与其他漏洞或控制内存布局的方法结合使用，可以远程触发此漏洞，例如，通过控制选择器。

尽管这确实是一个应修补的漏洞，但我们怀疑它是由攻击者试图利用以下漏洞而触发的。

第二个漏洞：MFMutable中的远程堆溢出

研究人员继续调查可疑的远程事件，并确定同一区域存在另一个漏洞。

回溯可以如下所示：

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] 
|
+--  -[MFMutableData appendData:]
    |
   +--  -[MFMutableData appendBytes:length:]
       |
       +-- -[MFMutableData _mapMutableData]

在分析代码流时，研究人员确定了以下内容：

[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]以原始MIME格式下载电子邮件时，将调用该函数，并且在以Exchange模式下载电子邮件之前，还将多次调用该函数。它将创建一个新NSMutableData对象，并对属于同一电子邮件/ MIME消息的任何新流数据调用appendData：。对于其他协议（如IMAP），它使用-[MFConnection readLineIntoData:]代替，但逻辑和漏洞相同。

NSMutableData将阈值设置为0x200000字节，如果数据大于0x200000字节，它将把数据写入文件，然后使用系统调用mmap将文件映射到设备内存。0x200000的阈值大小很容易被超过，因此每次需要添加新数据时，文件都会被重新映射，并且文件大小以及mmap大小会越来越大。

在内部重新映射完成-[MFMutableData _mapMutableData:]，漏洞存在该函数内部。

易受攻击的函数的伪代码如下：

系统调用mmap失败时，- [MFMutableData_mapMutableData:]调用函数MFMutableData__mapMutableData___block_invoke

伪代码MFMutableData__mapMutableData___block_invoke如下，它分配了一个大小为8的堆内存，然后用分配内存替换data->bytes指针。

执行-[MFMutableData _mapMutableData:]完之后，进程继续执行-[MFMutableData appendBytes:length:]，将数据复制到分配内存时导致堆溢出。

-[MFMutableData appendBytes:length:] 
{
  int length = [self length];
  //...
  bytes = self->bytes;
  if(!bytes){
     bytes = [self _mapMutableData]; //Might be a data pointer of a size 8 heap
  }
  copy_dst = bytes + length;
  //...
  platform_memmove(copy_dst, append_bytes, append_length); // It used append_length to copy the memory, causing an OOB writing in a small heap
}

append_length是来自流式传输的数据块的长度。由于这MALLOC_NANO是一个可预测的内存区域，因此可以利用此漏洞。

攻击者无需耗尽内存的每一个最后一位就可以使mmap失败，因为mmap需要一个连续的内存区域。

复现

根据mmap操作说明，在MAP_ANON was specified and insufficient memory was available时mmap会失败。

mmap失败是正常情况，理想情况下，电子邮件够大就不可避免地会发生。但是，可以使用其他可耗尽资源的技巧来触发漏洞。这些技巧可以通过多方面，比如RTF和其他格式来实现。

可能影响可利用性的另一个重要因素是硬件规格：

iPhone 6：1GB

iPhone 7：2GB

iPhone X：3GB

较旧的设备具有较小的物理RAM和较小的虚拟内存空间，因此不必耗尽RAM的每一位来触发此错误，当无法在可用虚拟内存中找到给定大小的连续内存空间时，mmap将失败。

目前已经确定MacOS不会同时受到这两个漏洞的攻击。

在iOS 12中，触发漏洞更容易，数据流传输是在同一过程中完成的，因为默认邮件应用程序（MobileMail）会处理更多的资源，从而耗尽了虚拟内存空间（尤其是UI）的分配渲染，而在iOS 13中，MobileMail将数据流传递到后台进程maild。它把资源集中在解析电子邮件上，从而降低了虚拟内存空间意外用完的风险。

远程复现

由于MobileMail / maild并未明确设置电子邮件大小的最大限制，因此可以设置自定义电子邮件服务器并发送具有几GB纯文本的电子邮件。iOS MIME /消息库在流传输数据时将数据平均分成大约0x100000字节，因此完全可以不下载整个电子邮件。

请注意，这只是如何触发此漏洞的一个示例。攻击者无需为了触发此漏洞而发送此类电子邮件，使用多种方式，比如RTF或其他格式等技巧，可以使用标准大小的电子邮件实现相同的目标。

披露时间表

2020年2月19日，根据ZecOps负责任的披露政策，向供应商报告了可疑事件，该事件允许立即发布在野触发因素；

受影响的供应商与ZecOps之间的持续进行攻击；

3月23日，ZecOps向受影响的供应商发送了OOB Write漏洞的POC复制信息；

3月25日，ZecOps共享了OOB Write的本地POC；

3月31日，ZecOps确认同一地区存在第二个漏洞，并且具有远程触发功能（远程堆溢出），这两个漏洞都是在野外触发的；

3月31日，ZecOps与受影响的供应商共享了POC，以解决远程堆溢出漏洞；

4月7日，ZecOps共享了一个自定义邮件服务器，只需在Mail中添加用户名和密码并下载电子邮件，即可轻松触发iOS 13.4 / 13.4.1上的0单击堆溢出漏洞；

4月15日至16日，供应商在公开测试版中修补了这两个漏洞；

4月20日，研究人员重新分析了历史数据，发现了VIP和目标人物在野外触发的其他证据，并发送了一封电子邮件，通知供应商，我们将必须立即发布此威胁通报，这样企业可以自我保护，因为攻击者（因为已在Beta中进行了修补）很可能会越来越活跃；

4月22日，公开披露。

参考链接：

零日警告：仅通过发送电子邮件就可以入侵iPhone

苹果手机和iPad应用存漏洞 或致5亿部iPhone易受黑客攻击

苹果表示iOS Mail漏洞不会立即构成威胁，补丁即将发布

*本文作者：Sandra1432，转载请注明来自FreeBuf.COM