正文

我是如何在4小时之内发现unc0ver越狱利用的0-day漏洞

admin
admin V管理员 /0 评论 /11 阅读
0321
此篇文章发布距今已超过1138天，您需要注意文章的内容或图片是否可用！

 

前言

2020年5月23日下午3点，unc0ver针对iOS 13.5（当时的最新版本）发布了越狱方法，其中利用了0-day漏洞并经过严重混淆。当天晚上7点，我已经成功定位到越狱过程中利用的0-day漏洞，并将漏洞报告给Apple。次日凌晨1点，我已经向Apple发送了PoC和分析信息。而这篇文章将详细介绍我的整个漏洞探索过程。

 

初步定位

我想要找到unc0ver利用的漏洞，并迅速将其报告给Apple，以证明对漏洞利用进行混淆，并不能有效地防止漏洞利用方法落入攻击者的手中。

在下载并解压缩unc0ver IPA之后，我将主要可执行文件加载到IDA中进行查看。但遗憾的是，二进制文件被严重混淆了，因此静态分析中出现的问题已经超出了我的能力范围。

接下来，我将unc0ver应用程序加载到运行iOS 13.2.3的iPod Touch 7上，尝试运行漏洞利用程序。通过探索应用程序界面，用户无法控制可以利用哪个漏洞来实现设备的越狱，因此我希望unc0ver仅利用了一个0-day漏洞，并且没有在iOS 13.3或更低版本上利用oob_timestamp漏洞。

当我单击“越狱”按钮时，我突然产生了一个想法：之前我写过一些内核漏洞利用程序，当时了解到大多数基于内存损坏的漏洞利用程序都有一个“关键段”，在此期间内核状态被破坏，如果漏洞利用程序的其余部分没有继续运行，那么系统将会不稳定。因此，我灵机一动，双击Home键打开应用程序切换器，并关闭了unc0ver应用程序。

设备立即就出现了错误（Panic）。

panic(cpu 1 caller 0xfffffff020e75424): "Zone cache element was used after free! Element 0xffffffe0033ac810 was corrupted at beginning; Expected 0x87be6c0681be12b8 but found 0xffffffe003059d90; canary 0x784193e68284daa8; zone 0xfffffff021415fa8 (kalloc.16)"
Debugger message: panic
Memory ID: 0x6
OS version: 17B111
Kernel version: Darwin Kernel Version 19.0.0: Wed Oct  9 22:41:51 PDT 2019; root:xnu-6153.42.1~1/RELEASE_ARM64_T8010
KernelCache UUID: 5AD647C26EF3506257696CF29419F868
Kernel UUID: F6AED585-86A0-3BEE-83B9-C5B36769EB13
iBoot version: iBoot-5540.40.51
secure boot?: YES
Paniclog version: 13
Kernel slide:     0x0000000019cf0000
Kernel text base: 0xfffffff020cf4000
mach_absolute_time: 0x3943f534b
Epoch Time:        sec       usec
  Boot    : 0x5ec9b036 0x0004cf8d
  Sleep   : 0x00000000 0x00000000
  Wake    : 0x00000000 0x00000000
  Calendar: 0x5ec9b138 0x0004b68b

Panicked task 0xffffffe0008a4800: 9619 pages, 230 threads: pid 222: unc0ver
Panicked thread: 0xffffffe004303a18, backtrace: 0xffffffe00021b2f0, tid: 4884
  lr: 0xfffffff007135e70  fp: 0xffffffe00021b330
  lr: 0xfffffff007135cd0  fp: 0xffffffe00021b3a0
  lr: 0xfffffff0072345c0  fp: 0xffffffe00021b450
  lr: 0xfffffff0070f9610  fp: 0xffffffe00021b460
  lr: 0xfffffff007135648  fp: 0xffffffe00021b7d0
  lr: 0xfffffff007135990  fp: 0xffffffe00021b820
  lr: 0xfffffff0076e1ad4  fp: 0xffffffe00021b840
  lr: 0xfffffff007185424  fp: 0xffffffe00021b8b0
  lr: 0xfffffff007182550  fp: 0xffffffe00021b9e0
  lr: 0xfffffff007140718  fp: 0xffffffe00021ba30
  lr: 0xfffffff0074d5bfc  fp: 0xffffffe00021ba80
  lr: 0xfffffff0074d5d90  fp: 0xffffffe00021bb40 
  lr: 0xfffffff0075f10d0  fp: 0xffffffe00021bbd0
  lr: 0xfffffff00723468c  fp: 0xffffffe00021bc80
  lr: 0xfffffff0070f9610  fp: 0xffffffe00021bc90
  lr: 0x00000001bf085ae4  fp: 0x0000000000000000

这看上去似乎很有希望，我得到的错误消息中描述，kalloc.16分配区（大小最大为16个字节的通用分配）中有一处释放后使用（UAF）。但是，这表明可能存在内存损坏。为了进行进一步调查，我需要分析回溯。

在等待IDA处理iPod的内核缓存的过程中，我尝试了一些现成的实验。由于许多漏洞利用都使用Mach端口作为基本原语，因此我编写了一个会搅乱ipc.ports区域，创建碎片，并混合可利用空间表（freelist）的应用程序。当我随后运行unc0ver应用程序时，该漏洞利用仍然有效，这表明它可能不依赖于对Mach端口分配的堆。

接下来，由于panic日志中提到了kalloc.16，因此我决定编写一个应用程序，该应用程序在unc0ver漏洞利用期间在后台连续分配，并释放给kalloc.16。这个想法在于，如果unc0ver依赖于重新分配kalloc.16的分配，那么我的应用程序可能会抢占该Slot，这可能会导致漏洞利用策略失败，并且可能导致内核崩溃。可以肯定的是，我的应用程序在后台对kalloc.16进行操作的过程中，如果点击“越狱”按钮，将会立即引起内核崩溃。

在进行健全性检查的过程中，我尝试更改应用程序，以尝试不同区域，这次选择的是kalloc.32而不再是kalloc.16。在这一次，漏洞利用成功运行，那么也就证明了，kalloc.16实际上才是漏洞利用的关键分配区域。

最后，一旦IDA完成对iPod内核缓存的分析后，我开始抽象地表示从崩溃日志中收集的堆栈跟踪。

Panicked task 0xffffffe0008a4800: 9619 pages, 230 threads: pid 222: unc0ver
Panicked thread: 0xffffffe004303a18, backtrace: 0xffffffe00021b2f0, tid: 4884
  lr: 0xfffffff007135e70
  lr: 0xfffffff007135cd0
  lr: 0xfffffff0072345c0
  lr: 0xfffffff0070f9610
  lr: 0xfffffff007135648
  lr: 0xfffffff007135990
  lr: 0xfffffff0076e1ad4  # _panic
  lr: 0xfffffff007185424  # _zcache_alloc_from_cpu_cache
  lr: 0xfffffff007182550  # _zalloc_internal
  lr: 0xfffffff007140718  # _kalloc_canblock
  lr: 0xfffffff0074d5bfc  # _aio_copy_in_list
  lr: 0xfffffff0074d5d90  # _lio_listio
  lr: 0xfffffff0075f10d0  # _unix_syscall
  lr: 0xfffffff00723468c  # _sleh_synchronous
  lr: 0xfffffff0070f9610  # _fleh_synchronous
  lr: 0x00000001bf085ae4

其中，对lio_listio()的调用立刻引起了我的注意。在我近期研究iOS内核漏洞利用的不久之前，我记得在之前LightSpeed的漏洞利用中，所使用的易受攻击的系统调用正是lio_listio()。于是，我重新阅读了Synacktiv的博客文章，以回顾该漏洞，随即发现了另一个问题：在LightSpeed竞争条件中被双重释放的目标对象是一个驻留在kalloc.16中的aio_lio_context对象。另外，unc0ver应用程序中存在的大量线程，进一步支持了竞争条件的这个思路。

到现在，我认为我已经有足够的证据可以联系Apple。经过初步分析，我发现该漏洞就是LightSpeed，可能是它的变体，或者就是本身。

 

编写PoC证明漏洞存在

接下来，我想通过编写PoC来触发漏洞，从而验证漏洞确实存在。我先尝试了LightSpeed文章中使用的原始PoC，但是在经过一分钟的运行后，没有出现崩溃。这表明，也许这里的0-day漏洞，是原始LightSpeed漏洞的变体。

为了找到更多信息，我开始进行更深入地调查。我查看XNU源代码，以尝试发现漏洞，同时我还使用checkra1n/pongoOS在内核缓存中修补lio_listio()，然后运行漏洞利用程序。从源代码上，我根本看不出来原始漏洞是如何修复的，这对我来说毫无意义。因此，我准备将精力集中在内核修补上。

要查看引导修补的内核高速缓存，这一过程非常复杂，但我们可以利用checkm8。我下载了checkra1n，并将iPod引导到pongoOS Shell中。以pongoOS repo中的示例为指导，我创建了一个可加载的pongo模块，该模块将禁用checkra1n内核补丁，而是应用我自己的补丁。在这里，之所以禁用checkra1n内核补丁，是因为我担心unc0ver会检测到checkra1n，并采取反分析措施。

我的第一个测试只是将无效的指令操作码插入到lio_listio()函数中，以便在调用时会出现崩溃。但没有想到的是，设备启动正常，然后在我点击“越狱”时，出现了崩溃。这意味着，unc0ver是唯一调用了lio_listio()函数的进程。

接下来，我修补了负责分配aio_lio_context对象的代码，该对象在原始LightSpeed漏洞中被双重释放，通过这样，我们可以让kalloc.48来进行分配，而不再是kalloc.16。

FFFFFFF0074D5D54     MOV     W8, #0xC ; patched to #0x23
FFFFFFF0074D5D58     STR     X8, [SP,#0x40] ; alloc size
FFFFFFF0074D5D5C     ADRL    X2, _lio_listio.site.5
FFFFFFF0074D5D64     ADD     X0, SP, #0x40
FFFFFFF0074D5D68     MOV     W1, #1 ; can block
FFFFFFF0074D5D6C     BL      kalloc_canblock
FFFFFFF0074D5D70     CBZ     X0, loc_FFFFFFF0074D6234
FFFFFFF0074D5D74     MOV     X19, X0 ; lio_context
FFFFFFF0074D5D78     MOV     W1, #0xC ; size_t
FFFFFFF0074D5D7C     BL      _bzero

这个想法在于，通过增加对象的分配大小，导致unc0ver的漏洞利用策略失败，因为它尝试用kalloc.16中的替换对象去替换意外释放的kalloc.48上下文中的对象，而这根本不会成功。可以肯定的是，有了这个补丁程序，unc0ver停在了“漏洞利用内核”阶段，而没有产生崩溃。

然后，我又进行了更多的实验，对函数的各个位置进行了修补，以转储传递给lio_listio()的参数和数据缓冲区，以便可以与原始LightSpeed PoC中使用的值进行比较。我的想法是，如果我发现任何实质性差异，那么我就可以考虑使用源代码的变体。但是，除了将字段aio_reqprio设置为gang之外，unc0ver传递给lio_listio()的参数与原始PoC中的参数之间没有差别。

此时，看来这个0-day可能就是原始的LightSpeed漏洞，而不是变体。因此，我又开始分析原始的PoC，查看未触发漏洞利用的原因是否由于特定的技术已经被缓解。负责重新分配kalloc.16分配的代码引起了我的关注：

/* not mandatory but used to make the race more likely */
/* this poll() will force a kalloc16 of a struct poll_continue_args */
/* with its second dword as 0 (to collide with lio_context->io_issued == 0) */
/* this technique is quite slow (1ms waiting time) and better ways to do so exists */
int n = poll(NULL, 0, 1);

我以前从来没有见过使用poll()作为重新分配原语。从直观上看，使用基于Mach端口的重新分配策略似乎更有希望，因此我用从oob_timestamp复制的Out-of-line Mach端口喷射替换了这部分代码。果然，在几秒钟之内，我们的PoC就成功触发了。而这里就是需要对PoC进行的唯一修改。

 

补丁历史

在有了可以使用的PoC之后，我重试了原始的LightSpeed PoC，发现如果将其运行足够长的时间，最终还是能导致崩溃。因此，这是重新引入漏洞的另一种情况，该漏洞可以通过简单的回归测试来确定。

因此，让我们回到源头，看看是否可以弄清楚发生了什么。如前所述，当我第一次检查XNU源代码并查看lio_listio()是如何被破坏的时候，我实际上根本无法确定该漏洞最初是如何修补的。但是现在回想，似乎并不是毫无踪迹可寻。

最初的LightSpeed文章很好地描述了该漏洞，我在这里就不做赘述，我强烈建议各位读者阅读这篇文章。从更高的角度来看，我们尚不清楚是哪个函数释放的aio_lio_context对象，因为执行异步I/O的辅助线程和lio_listio()函数自身都可以做到这一点。

正如在文章中提到的那样，该漏洞的原始修补程序只是在可能双重释放的情况下不再释放aio_lio_context对象：

“该修补程序将潜在的UaF固定在lio_context上。但是，这样的修复方式忽略了在修复之前处理的错误情况。最终的结果导致可以使用lio_listio()分配aio_lio_context，而内核将永远不会释放aio_lio_context。这样一来，我们就获得了一个愚蠢的DoS，还会导致最新版本的内核（包括iOS 12）崩溃。

对于剩下的这部分，我们可以在以后看到，Apple是否愿意修复补丁中引入的DoS风险。”

事实证明，Apple最终决定在iOS 13中修复了内存泄漏漏洞，但是这样做似乎导致重新引入了双重释放的竞争条件：

    case LIO_NOWAIT:
+       /* If no IOs were issued must free it (rdar://problem/45717887) */
+       if (lio_context->io_issued == 0) {
+           free_context = TRUE;
+       }
        break;

iOS 13中的代码与iOS 11并不完全相同，但是在语义上是等效的。如果我们理解原始LightSpeed漏洞，就可以通过查看XNU源代码之间的差异，轻松地判断出二者之间的关联性。进行简单的回归测试后，就可以轻松发现这个漏洞。

总而言之，LightSpeed漏洞已经在iOS 12中实现了修复，但是补丁没有解决根本问题，只是将竞争条件双重释放转换为内存泄漏。此后，在iOS 13中，发现了这个内存泄漏漏洞，并通过重新引入原始漏洞实现了“修复”，但在此过程中仍然没有解决问题的根本原因。通过执行博客文章的原始PoC，可以证明其安全性的降低。

我们可以在Synacktiv博客的后续文章中，阅读有关这一漏洞的更多信息。

 

总结

iOS 12.4中的SockPuppet和iOS 13中的LightSpeed都表明，Apple至少没有针对这些旧的安全漏洞进行有效的回归测试。开展有效的回归测试是基本软件测试的必要条件，也是漏洞利用的一个共同起点。

不过，在漏洞利用程序公开后，Apple及时地修复了这个问题。现在的情况在于，在公开发布PoC之前很久，攻击者就已经发现了这些问题。因此，攻击者可能正在积极地开展漏洞利用的回归测试。

另外，在此次研究中，我们也证明了，混淆处理并不会阻止攻击者迅速发现漏洞利用方法。事实证明，我的分析过程中非常幸运，依靠我之前编写内核漏洞利用的经验，我迅速找到了该漏洞利用的替代方案，并且由于我一直在关注过去出现的漏洞，所以我也刚好熟悉所利用的特定漏洞。但是，对于持续关注Apple设备的攻击者或组织，他们也很可能拥有与我相同的优势。