在ZecOps 团队宣布在iOS的默认邮件应用程序中发现RCE漏洞之后，已经有很多用户联系了他们，他们怀疑自己成为了这个漏洞的攻击目标。
在这篇文章中，我们将介绍一种简单的方法来喷洒堆，通过这种方法，我们可以证明远程利用这个漏洞是可能的。除此之外，我们还将提供两个在野外观察到的触发器示例。
目前，我们已经发现了该漏洞具有以下攻击性能：
1.邮件应用程序中的远程堆溢出；
2.能够通过传入邮件由攻击者控制的输入内容来远程触发漏洞；
3.改变代码执行的能力；
4.事实提升访问内核的权限；
不过，我们并没有发现该漏洞可以泄漏消息，但让人感到惊讶是，信息泄漏并不是存在于邮件中，而是存在于其他过程中。因为dyld_shared_cache是通过大多数进程共享的，因此信息泄漏漏洞不一定必须存在于MobileMail中，例如iMessage的CVE-2019-8646也可以远程实现这个功能，这就打开了额外的攻击面(Facetime、其他应用、iMessage等)。本文，我们会远程利用这个漏洞所具有的所有特性。尽管如此，我们还是要做以下说明：
1.我们无意公开LPE，它允许我们在需要时对A12及更高版本的设备执行文件系统提取或内存检查。你可以在FreeTheSandbox.org 上了解更多关于移动设备的漏洞信息。
2.我们还没有在野外看到对本地特权升级(LPE)漏洞的利用；
我们还将分享我们在野外看到的两个触发器示例，并让你做出自己的推断和结论。
MailDemon赏金
最后，对于那些能够证明他们遭到攻击的示例，我们将提供赏金。
利用MailDemon
如前所述，MailDemon是一个很好的利用对象，因为它覆盖了MALLOC_NANO内存区域的模块，而MALLOC_NANO内存区域存储了大量的Objective-C对象。因此，它允许攻击者操纵已被攻击对象的ISA指针(允许他们引起类型混淆)或重写函数指针来控制进程的代码流，这是接管受影响过程的可行方法。
堆喷和堆整理技术
为了控制代码流，需要进行堆喷射以将制作的数据放入内存中。使用包含“dealloc”方法的伪方法缓存的伪造类，我们可以使用此方法触发漏洞后控制程序计数器（PC）寄存器。
下面是测试POC时生成的部分崩溃日志:
Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Subtype: EXC_ARM_DA_ALIGN at 0xdeadbeefdeadbeef VM Region Info: 0xdeadbeefdeadbeef is not in any region. Bytes after previous region: 16045690973559045872 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_NANO 0000000280000000-00000002a0000000 [512.0M] rw-/rwx SM=PRV ---> UNUSED SPACE AT END Thread 18 name: Dispatch queue: com.apple.CFNetwork.Connection Thread 18 Crashed: 0 ??? 0xdeadbeefdeadbeef 0 + -2401053088876216593 1 libdispatch.dylib 0x00000001b7732338 _dispatch_lane_serial_drain$VARIANT$mp + 612 2 libdispatch.dylib 0x00000001b7732e74 _dispatch_lane_invoke$VARIANT$mp + 480 3 libdispatch.dylib 0x00000001b773410c _dispatch_workloop_invoke$VARIANT$mp + 1960 4 libdispatch.dylib 0x00000001b773b4ac _dispatch_workloop_worker_thread + 596 5 libsystem_pthread.dylib 0x00000001b796a114 _pthread_wqthread + 304 6 libsystem_pthread.dylib 0x00000001b796ccd4 start_wqthread + 4 Thread 18 crashed with ARM Thread State (64-bit): x0: 0x0000000281606300 x1: 0x00000001e4b97b04 x2: 0x0000000000000004 x3: 0x00000001b791df30 x4: 0x00000002827e81c0 x5: 0x0000000000000000 x6: 0x0000000106e5af60 x7: 0x0000000000000940 x8: 0x00000001f14a6f68 x9: 0x00000001e4b97b04 x10: 0x0000000110000ae0 x11: 0x000000130000001f x12: 0x0000000110000b10 x13: 0x000001a1f14b0141 x14: 0x00000000ef02b800 x15: 0x0000000000000057 x16: 0x00000001f14b0140 x17: 0xdeadbeefdeadbeef x18: 0x0000000000000000 x19: 0x0000000108e68038 x20: 0x0000000108e68000 x21: 0x0000000108e68000 x22: 0x000000016ff3f0e0 x23: 0xa3a3a3a3a3a3a3a3 x24: 0x0000000282721140 x25: 0x0000000108e68038 x26: 0x000000016ff3eac0 x27: 0x00000002827e8e80 x28: 0x000000016ff3f0e0 fp: 0x000000016ff3e870 lr: 0x00000001b6f3db9c sp: 0x000000016ff3e400 pc: 0xdeadbeefdeadbeef cpsr: 0x60000000
在这种示例下，堆喷射的理想原语是可以从远程触发的内存泄漏漏洞，因为我们希望所喷洒的内存在触发内存破坏之前保持不变。另一种方法是使用MFMutableData本身，当MFMutableData的大小小于0x20000字节时，它从堆中分配内存，而不是创建一个文件来存储内容。我们可以通过将电子邮件的内容分割成小于0x20000字节的行来控制MFMutableData的大小，因为IMAP库是按行读取电子邮件内容的。使用这个原语，我们有更好的机会将有效载荷放置到我们想要的地址中。
触发过程
一个过大的电子邮件能够复制漏洞作为一个PoC ，但是要获得稳定的利用，我们需要仔细研究“-[MFMutableData appendBytes:length:]“。
-[MFMutableData appendBytes:length:]
{
int old_len = [self length];
//...
char* bytes = self->bytes;
if(!bytes){
bytes = [self _mapMutableData]; //Might be a data pointer of a size 8 heap
}
copy_dst = bytes + old_len;
//...
memmove(copy_dst, append_bytes, append_length); // It used append_length to copy the memory, causing an OOB writing in a small heap
}memove的目标地址是 ”bytes + old_len”，而不是“bytes”。那么，如果在触发漏洞之前我们积累了太多数据该怎么办？考虑到MALLOC_NANO区域的大小为512MB， “old_len”将以一个非常大的值结束，因此目标地址将以超出该区域边界的无效地址结束并立即崩溃。
为了减少“填充”的大小，我们需要在触发漏洞之前消耗尽可能多的数据。此时，内存泄漏就会必然发生。
值得注意的是，“填充”并不意味着溢出地址是完全随机的，由于硬件大小相同，因此硬件模型可以预测“填充”，因为在我们的测试中，相同大小的mmap通常会失败。
崩溃分析
这篇文章讨论了在以前的文章中介绍的在野外检测到的MobileMail漏洞的几种触发因素和可利用性。
示例1显示，该漏洞在被披露之前就在野外被触发。
示例2是由于MALLOC_NANO区域中的内存损坏，损坏的内存的值是已发送电子邮件的一部分，并完全由发件人控制。
示例1
当发生溢出时，易受攻击的函数内部立即触发了以下崩溃。
Coalition: com.apple.mobilemail [521] Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x000000004a35630e //[a] VM Region Info: 0x4a35630e is not in any region. Bytes before following region: 3091946738 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 000000010280c000-0000000102aec000 [ 2944K] r-x/r-x SM=COW ...p/MobileMail] Thread 4 Crashed: 0 libsystem_platform.dylib 0x00000001834a5a80 _platform_memmove + 208 0x1834a5a74 ldnp x10, x11, [x1, #16] 0x1834a5a78 add x1, x1, 0x20 0x1834a5a7c sub x2, x2, x5 0x1834a5a80 stp x12, x13, [x0] //[b] 0x1834a5a84 stp x14, x15, [x0, #16] 0x1834a5a88 subs x2, x2, 0x40 0x1834a5a8c b.ls 0x00002ab0 1 MIME 0x00000001947ae104 -[MFMutableData appendBytes:length:] + 356 2 Message 0x0000000194f6ce6c -[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] + 804 3 DAEAS 0x000000019ac5ca8c -[ASAccount folderItemsSyncTask:handleStreamOperation:forCodePage:tag:withParentItem:withData:dataLength:] + 736 4 DAEAS 0x000000019aca3fd0 -[ASFolderItemsSyncTask handleStreamOperation:forCodePage:tag:withParentItem:withData:dataLength:] + 524 5 DAEAS 0x000000019acae338 -[ASItem _streamYourLittleHeartOutWithContext:] + 440 6 DAEAS 0x000000019acaf4d4 -[ASItem _streamIfNecessaryFromContext:] + 96 7 DAEAS 0x000000019acaf758 -[ASItem _parseNextValueWithDataclass:context:root:parent:callbackDict:streamCallbackDict:parseRules:account:] + 164 8 DAEAS 0x000000019acb001c -[ASItem parseASParseContext:root:parent:callbackDict:streamCallbackDict:account:] + 776 9 DAEAS 0x000000019acaf7d8 -[ASItem _parseNextValueWithDataclass:context:root:parent:callbackDict:streamCallbackDict:parseRules:account:] + 292 10 DAEAS 0x000000019acb001c -[ASItem parseASParseContext:root:parent:callbackDict:streamCallbackDict:account:] + 776 ... Thread 4 crashed with ARM Thread State (64-bit): x0: 0x000000004a35630e x1: 0x00000001149af432 x2: 0x0000000000001519 x3: 0x000000004a356320 x4: 0x0000000100000028 x5: 0x0000000000000012 x6: 0x0000000c04000100 x7: 0x0000000114951a00 x8: 0x44423d30443d3644 x9: 0x443d30443d38463d x10: 0x3d31413d31443d30 x11: 0x31413d31463d3444 x12: 0x33423d30453d3043 x13: 0x433d30443d35423d x14: 0x3d30443d36443d44 x15: 0x30443d38463d4442 x16: 0x00000001834a59b0 x17: 0x0200080110000100 x18: 0xfffffff00a0dd260 x19: 0x000000000000152b x20: 0x00000001149af400 x21: 0x000000004a35630e x22: 0x000000004a35630f x23: 0x0000000000000008 x24: 0x000000000000152b x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x00000001149af400 x28: 0x000000018dbd34bc fp: 0x000000016da4c720 lr: 0x00000001947ae104 sp: 0x000000016da4c720 pc: 0x00000001834a5a80 cpsr: 0x80000000
对于[a]和[b]，我们知道进程在“memmove”中崩溃，这个进程被“-[MFMutableData appendBytes:length:]”调用，这意味着“copy_dst”的值首先是一个无效地址，即0x4a35630e。
那么寄存器x0 (0x4a35630e)的值是从哪里来的呢?因为，它比最低有效地址小得多。
结果是，当在mmap文件失败后，同时分配8字节内存失败时，进程就会崩溃。
无效地址0x4a35630e实际上是触发漏洞之前MFMutableData的长度偏移量(即“old_len”)。当calloc分配内存失败时，它返回NULL，因此copy_dst将是“0 + old_len(0x4a35630e)”。
在本例中，“old_len”约为1.2GB，这与POC的平均长度相匹配，这可能会导致mmap失败并触发漏洞。
请注意，x8-x15和x0完全由发送者控制。
这次崩溃为我们的上述问题（如果我们在触发漏洞之前积累了太多的数据，会怎么样?）提供了另一个答案，8字节内存的分配可能会失败并崩溃，而将有效载荷复制到一个无效的地址。这可能使可靠的利用变得更加困难，因为我们可能在接管程序计数器之前崩溃。
回顾2010年iOS 3.1.3中的神秘触发！
值得注意的是，我们在modmy.com论坛上找到了一个匿名用户完全类似的触发事件的公开示例：
漏洞版本：iPhone 2G上的iOS 3.1.3；
发生时间:2010年10月22日；
用户“shyamsandeep”于2008年6月12日注册，最后一次登录是在2011年10月16日，在论坛中只有一篇帖子，其中就包含了这个触发事件。
这个崩溃的r0等于0x037ea000，这可能是我们在之前的文章中披露的第一个漏洞，这是由于ftruncate()失败造成的。有趣的是，正如我们在第一种示例中所解释的，它也可能是分配8字节内存失败的结果，但是由于日志缺少内存区域信息，因此无法确定确切原因。但是，可以肯定的是，自2010年以来，这个可利用漏洞的触发因素很多。
Identifier: MobileMail Version: ??? (???) Code Type: ARM (Native) Parent Process: launchd [1] Date/Time: 2010-10-22 08:14:31.640 +0530 OS Version: iPhone OS 3.1.3 (7E18) Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x037ea000 Crashed Thread: 4 Thread 4 Crashed: 0 libSystem.B.dylib 0x33aaef3c 0x33aad000 + 7996 //memcpy + 0x294 1 MIME 0x30a822a4 0x30a7f000 + 12964 //_FastMemoryMove + 0x44 2 MIME 0x30a8231a 0x30a7f000 + 13082 // -[MFMutableData appendBytes:length:] + 0x6a 3 MIME 0x30a806d6 0x30a7f000 + 5846 // -[MFMutableData appendData:] + 0x32 4 Message 0x342e2938 0x34251000 + 596280 // -[DAMessageContentConsumer consumeData:length:format:mailMessage:] + 0x25c 5 Message 0x342e1ff8 0x34251000 + 593912 // -[DAMailAccountSyncConsumer consumeData:length:format:mailMessage:] +0x24 6 DataAccess 0x34146b22 0x3413e000 + 35618 // -[ASAccount folderItemsSyncTask:handleStreamOperation:forCodePage:tag:withParentItem:withData:dataLength:] + 0x162 7 DataAccess 0x3416657c 0x3413e000 + 165244 //[ASFolderItemsSyncTaskhandleStreamOperation:forCodePage:tag:withParentIt em:withData:dataLength:] + 0x108 ... Thread 4 crashed with ARM Thread State: r0: 0x037ea000 r1: 0x008729e0 r2: 0x00002205 r3: 0x4e414153 r4: 0x41415367 r5: 0x037e9825 r6: 0x00872200 r7: 0x007b8b78 r8: 0x0001f825 r9: 0x001fc098 r10: 0x00872200 r11: 0x0087c200 ip: 0x0000068a sp: 0x007b8b6c lr: 0x30a822ab pc: 0x33aaef3c cpsr: 0x20000010
示例2
以下是在收到并处理电子邮件之后发生的另一次崩溃：
Coalition: com.apple.mobilemail [308] Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0041004100410041 // [a] VM Region Info: 0x41004100410041 is not in any region. Bytes after previous region: 18296140473139266 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL mapped file 00000002d31f0000-00000002d6978000 [ 55.5M] r--/rw- SM=COW ...t_id=9bfc1855 ---> UNUSED SPACE AT END Thread 13 name: Dispatch queue: Internal _UICache queue Thread 13 Crashed: 0 libobjc.A.dylib 0x00000001b040fca0 objc_release + 16 0x1b040fc94 mov x29, sp 0x1b040fc98 cbz x0, 0x0093fce4 0x1b040fc9c tbnz x0, #63, 0x0093fce4 0x1b040fca0 ldr x8, [x0] // [b] 0x1b040fca4 and x8, x8, 0xffffffff8 0x1b040fca8 ldrb w8, [x8, #32] 0x1b040fcac tbz w8, #2, 0x0093fd14 1 CoreFoundation 0x00000001b1119408 -[__NSDictionaryM removeAllObjects] + 600 2 libdispatch.dylib 0x00000001b0c5d7d4 _dispatch_client_callout + 16 3 libdispatch.dylib 0x00000001b0c0bc1c _dispatch_lane_barrier_sync_invoke_and_complete + 56 4 UIFoundation 0x00000001bb9136b0 __16-[_UICache init]_block_invoke + 76 5 libdispatch.dylib 0x00000001b0c5d7d4 _dispatch_client_callout + 16 6 libdispatch.dylib 0x00000001b0c0201c _dispatch_continuation_pop$VARIANT$mp + 412 7 libdispatch.dylib 0x00000001b0c11fa8 _dispatch_source_invoke$VARIANT$mp + 1308 8 libdispatch.dylib 0x00000001b0c0ee00 _dispatch_kevent_worker_thread + 1224 9 libsystem_pthread.dylib 0x00000001b0e3e124 _pthread_wqthread + 320 10 libsystem_pthread.dylib 0x00000001b0e40cd4 start_wqthread + 4 Thread 13 crashed with ARM Thread State (64-bit): x0: 0x0041004100410041 x1: 0x00000001de1ac18a x2: 0x0000000000000000 x3: 0x0000000000000010 x4: 0x00000001b0c60388 x5: 0x0000000000000010 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x0000000281f94090 x9: 0x00000001b143f670 x10: 0x0000000142846800 x11: 0x0000004b0000007f x12: 0x00000001428468a0 x13: 0x000041a1eb487861 x14: 0x0000000283ed9d10 x15: 0x0000000000000004 x16: 0x00000001eb487860 x17: 0x00000001b11191b0 x18: 0x0000000000000000 x19: 0x0000000281dce4c0 x20: 0x0000000282693398 x21: 0x0000000282693330 x22: 0x0000000000000000 x23: 0x0000000000000000 x24: 0x0000000281dce4c8 x25: 0x000000000c000000 x26: 0x000000000000000d x27: 0x00000001eb48e000 x28: 0x0000000282693330 fp: 0x000000016b8fe820 lr: 0x00000001b1119408 sp: 0x000000016b8fe820 pc: 0x00000001b040fca0 cpsr: 0x20000000
[a]:对象的指针被“0x00410041004100410041”覆盖，它在unicode中是AAAA。
[b]是我们为更好地理解而添加的关于崩溃地址的指令之一，当-[nsdictionarym removeAllObjects]试图释放一个对象时，进程在指令“ldr x8, [x0]”上崩溃。
通过逆向工程-[nsdictionarym removeAllObjects]，我们可以理解寄存器x0是从x28(0x0000000282693330)加载的，因为在崩溃之前，寄存器x28从未被更改过。
让我们看一下x28: 0x0000000282693330的虚拟内存区域信息，覆盖的对象存储在MALLOC_NANO区域，该区域存储小堆块。堆溢出漏洞会破坏同一个区域，因为它会溢出一个8字节的堆块，这个堆块也存储在MALLOC_NANO中。
MALLOC_NANO 0x0000000280000000-0x00000002a0000000 rw-/rwx
这个崩溃实际上非常接近于控制PC，因为它控制了Objective-C对象的指针。通过将寄存器x0的值指向一个带有伪对象和伪方法缓存的类的内存，攻击者可以控制PC指针。
总结
1.很少看到用户提供的输入触发和控制远程漏洞；
2.如上所述，利用这个漏洞是可能的；
3.如上所述，现实中的触发器具有较大的分配值；
4.如上所述，现实中的触发器的值是由发送方控制的；
5.我们寻找的电子邮件丢失/删除了；
6.这个漏洞在2010年的iPhone 2G设备上就有了；
苹果如何改进日志?
iOS日志中缺少详细信息，而且缺少为个人和组织选择数据粒度的选项，因此需要进行更改，以使iOS能够与MacOS、Linux和Windows功能相媲美。总的来说，为了分析手机是如何被入侵的而侵入手机的做法是完全错误的，但却是迫不得已。
为此，我们建议苹果改进其漏洞诊断流程，以帮助个人、组织和软件开发者调查他们的设备。我们的建议如下：
1.改进崩溃：启用查看每个指针/寄存器旁边的内存的功能
2.改善崩溃：显示堆栈/堆内存/寄存器附近的内存；
3.将PID / PPID / UID / EUID添加到所有适用的事件；
4.无需物理连接即可将这些日志发送到远程服务器，在多个示例中，日志被神秘地删除；
5.能够对可疑的iOS设备进行完整的数字取证分析，而不需要先侵入设备；
还没有评论，来说两句吧...