新款iPhone SE开售前夕，iOS被曝存在八年的0day漏洞 |
| 来源：聚铭网络 发布时间：2020-04-24 浏览次数： |
信息来源：Freebuf
近日，安全研究人员发现iPhone和iPad自带的默认邮件应用程序MobileMail 和Maild存在两个正在被在野利用的严重漏洞，而且至少在两年前就已经开始监视用户了。 这两个漏洞允许远程攻击者秘密获取苹果设备的控制权，只要向已经登录邮件账号的用户设备发送电子邮件即可。这可能会使超过5亿部iPhone容易受到黑客的攻击。同时，iPad也存在这一问题。
旧金山的一家手机安全取证公司ZecOps在周三发布的一份报告中表示，在2019年末调查一起客户网络攻击事件时，发现了该问题。ZecOps创始人Zuk Avraham表示，他发现证据显示，这一漏洞至少在六起网络入侵事件中被利用。
Zuk推特声明 该漏洞是存在于苹果自带邮件应用程序中的MIME库中的远程代码执行漏洞，首先是因为越界写入错误，其次是堆溢出问题。 尽管两个电子邮件都是在处理邮件时触发的，但是第二个漏洞更为严重一些，因为其可以实现“零点击”利用，无需任何用户交互。
报告中还提及疑似遭受攻击的目标：
八年零日漏洞在野利用据研究员表明，两个漏洞存在iPhone 和iPad多个版本中长达8年，可以追溯到iOS6，甚至影响了当前的iOS 13.4.1，常规版本尚且没有补丁更新。 更让人担忧的是，多个攻击者组织长期利用这些漏洞（至少在野零日攻击中利用了2年最早可追溯到2018年1月）。 研究人员说：“目前公布的攻击数据有限，但是至少有6个组织或者个体遭受攻击，影响力还是很大的。尽管ZecOps没有发现攻击的幕后黑手，但是我们了解到至少有一个“雇佣组织”在销售该漏洞利用，并将电子邮件地址作为唯一标识符。 此外，对于苹果用户本身来说是很难意识到黑客的入侵的，因为他们在获取用户远程操控之后，可以立即删除恶意电子邮件。
除了邮件使用速度的短暂下降以外，用户没法发现任何的异常行为。成功的漏洞利用是让黑客在MobileMail 或者Maild 应用程序中执行恶意代码，并窃取、修改或者删除邮件。
然而，想要完全操控设备，黑客还需要一个助手，即单独的内核漏洞（比如无法修补的Checkm8漏洞）。尽管目前研究人员还没有发现黑客使用的恶意软件细节，但是邮件的漏洞和内核漏洞结合使用来监控他们的目标用户也不是没有可能。 当心！目前尚无可用补丁研究人员在两个月前发现这次的在野利用攻击，并将其报告给苹果安全团队。 截至发文，只有iOS13.4.5 beta版本在上周发布，包含了这两个漏洞的安全补丁。
而数百外的iPhone 和iPad用户还需等待下一次的软件安全补丁更新。与此同时，强烈建议苹果用户不要使用设备内置的邮件应用程序。 漏洞详情ZecOps发现，在MIME库中的执行MFMutableData，没有对系统调用ftruncate()进行错误检查，这会导致越界写入。研究人员找到了一种无需等待系统调用ftruncate失败即可触发OOB-Write的方法。此外，他们还发现可以远程触发的堆溢出。 事实上，这两种漏洞都是远程触发的。 OOB写入错误和堆溢出错误都是由于相同的问题而发生的：未正确处理系统调用的返回值。 远程错误可以在处理下载电子邮件时触发，在这种情况下，电子邮件将无法完全下载到设备上。
事故取证分析用户经历的部分崩溃（多次崩溃中的一部分）如下。 崩溃指令是stnp x8, x9, [x3]，这意味着价值x8，并x9已写入x3并坠毁由于访问无效的地址0x000000013aa1c000，其存储在x3。 Thread3Crashed: 0 libsystem_platform.dylib 0x000000019e671d88_platform_memmove+88 0x19e671d84 b.ls0x00008da8 0x19e671d88 stnpx8,x9,[x3] 0x19e671d8c stnpx10,x11,[x3, #16] 0x19e671d90 addx3,x3, 0x20 0x19e671d94 ldnpx8,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() andtruncate() cause thefilenamedbypath,orreferencedbyfildes,tobe truncated (orextended)tolengthbytesinsize.Ifthefilesizeexceedslength,anyextradataisdiscarded.Ifthefilesizeissmallerthanlength, thefileisextendedandfilledwithzerostothe indicatedlength. The ftruncate()formrequires thefiletobeopenforwriting.RETURNVALUESAvalueof0isreturnedifthecallsucceeds.Ifthecallfails a-1isreturned,andtheglobalvariableerrno specifies theerror. 主页显示：“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] 在分析代码流时，研究人员确定了以下内容：
易受攻击的函数的伪代码如下： 系统调用mmap失败时，- [MFMutableData_mapMutableData:]调用函数MFMutableData__mapMutableData___block_invoke
伪代码MFMutableData__mapMutableData___block_invoke如下，它分配了一个大小为8的堆内存，然后用分配内存替换data->bytes指针。
执行-[MFMutableData _mapMutableData:]完之后，进程继续执行-[MFMutableData appendBytes:length:]，将数据复制到分配内存时导致堆溢出。 -[MFMutableDataappendBytes:length:] { int length = [selflength]; //... bytes =self->bytes; if(!bytes){ bytes = [self_mapMutableData];//Might be a data pointer of a size8heap } copy_dst = bytes + length; //... platform_memmove(copy_dst, append_bytes, append_length);//It used append_length to copy the memory, causing an OOB writingina small heap } append_length是来自流式传输的数据块的长度。由于这MALLOC_NANO是一个可预测的内存区域，因此可以利用此漏洞。 攻击者无需耗尽内存的每一个最后一位就可以使mmap失败，因为mmap需要一个连续的内存区域。 复现根据mmap操作说明，在MAP_ANON was specified and insufficient memory was available时mmap会失败。 mmap失败是正常情况，理想情况下，电子邮件够大就不可避免地会发生。但是，可以使用其他可耗尽资源的技巧来触发漏洞。这些技巧可以通过多方面，比如RTF和其他格式来实现。 可能影响可利用性的另一个重要因素是硬件规格：
较旧的设备具有较小的物理RAM和较小的虚拟内存空间，因此不必耗尽RAM的每一位来触发此错误，当无法在可用虚拟内存中找到给定大小的连续内存空间时，mmap将失败。 目前已经确定MacOS不会同时受到这两个漏洞的攻击。 在iOS 12中，触发漏洞更容易，数据流传输是在同一过程中完成的，因为默认邮件应用程序（MobileMail）会处理更多的资源，从而耗尽了虚拟内存空间（尤其是UI）的分配渲染，而在iOS 13中，MobileMail将数据流传递到后台进程maild。它把资源集中在解析电子邮件上，从而降低了虚拟内存空间意外用完的风险。 远程复现由于MobileMail / maild并未明确设置电子邮件大小的最大限制，因此可以设置自定义电子邮件服务器并发送具有几GB纯文本的电子邮件。iOS MIME /消息库在流传输数据时将数据平均分成大约0×100000字节，因此完全可以不下载整个电子邮件。 请注意，这只是如何触发此漏洞的一个示例。攻击者无需为了触发此漏洞而发送此类电子邮件，使用多种方式，比如RTF或其他格式等技巧，可以使用标准大小的电子邮件实现相同的目标。 披露时间表
|
