更多全球网络安全资讯尽在E安全官网www.easyaq.com
议题概要
现代操作系统基本都已经在硬件级别（MMU）支持了用户态只读内存，只读内存映射在保证了跨进程间通信、用户态与内核间通信高效性的同时，也保证了其安全性。直到 DirtyCOW 漏洞的出现，这种信任边界被彻底打破。
在 iOS 中，这样的可信边界似乎是安全的，然而随着苹果设备的快速更新和发展，引入了越来越多的酷炫功能。许多酷炫功能依赖 iOS 与一些独立芯片的共同协作。其中，DMA（直接内存访问）技术让 iOS 与这些独立芯片之间的数据通信变得更加高效。然而，很少有人意识到，这些新功能的引入，悄然使得建立已久的可信边界被打破。
科恩实验室经过长时间的研究，发现了一些间接暴露给用户应用的 DMA 接口。虽然 DMA 的通信机制设计的比较完美，但是在软件实现层出现了问题。将一系列的问题串联起来后，将会形成了一个危害巨大的攻击链，甚至可导致 iOS 手机被远程越狱。部分技术曾在去年的 MOSEC 大会上进行演示，但核心细节与技术从未被公开。该议题将首次对这些技术细节、漏洞及利用过程进行分享，揭示如何串联多个模块中暴露的“不相关”问题，最终获取 iOS 内核最高权限的新型攻击模式。
陈良，腾讯安全科恩实验室安全研究专家，专注于浏览器高级利用技术、Apple系操作系统(macOS/iOS)的漏洞挖掘与利用技术研究。他曾多次带领团队获得Pwn2Own 、Mobile Pwn2Own 的冠军，并多次实现针对 iOS 系统的越狱。
议题解析
现代操作系统都会实现内存保护机制，让攻击变得更困难。iOS 在不同级别实现了这样的内存保护，例如，MMU 的 TBE 属性实现 NX、PXN、AP 等，以及更底层的 KPP、AMCC 等：
其中，用户态只读内存机制，在 iOS 上有很多应用，比如可执行页只读、进程间只读以及内核到用户态内存的只读：
如果一旦这些只读内存的保护被破坏，那么最初的可信边界就会被彻底破坏，在多进程通信的模式下，这可以导致沙盒绕过。而对于内核和用户态内存共享模式下，这可能可以导致内核代码执行：
然而突破这样的限制并不容易，在 iOS 中，内核代码会阻止这样的情况发生：每个内存页都有一个 max_prot 属性，如果这个属性设置为不能大于只读，那么所有设置成 writable 的重映射请求都会被阻止：
随着手机新技术的发展，DMA 技术也被应用于手机上，DMA 是一种让内存可以不通过 CPU 进行处理的技术，也就是说，所有CPU级别的内存保护，对于 DMA 全部无效。
那么，是不是说，DMA 没有内存保护呢？事实并非如此，这是因为两个原因：第一，对于64位手机设备，许多手机的周边设备（例如 WIFI 设备）还是32位的，这使得有必要进行64位和32位地址间转换；第二是因为 DMA 技术本身需要必要的内存保护。
正因为如此，IOMMU 的概念被提出了。在 iOS 设备中，DART 模块用来实现这样的地址转换。
事实上DMA有两种：Host-to-device DMA 以及 device-to-host DMA，前者用于将系统内存映射到设备，而后者用户将设备内存映射于系统虚拟内存。在2017年中，Google Project Zero 的研究员 Gal Beniamini 先将 WIFI 芯片攻破，然后通过修改 Host-to-device DMA 的一块内存，由于内核充分信任这块内存，忽略了一些必要的边界检查，导致成功通过 WIFI 来攻破整个 iOS 系统：
然而 Gal 的攻击方式存在一定局限，因为必须在短距离模式下才能完成：攻击 WIFI 芯片需要攻击者和受害者在同一个 WIFI 环境中。
我们有没有办法通过 DMA 的问题实现远距离攻破，这听上去并不可行，因为 DMA 接口本身并不会暴露于 iOS 用户态。
然而通过科恩实验室的研究发现，可能存在一些间接接口，可以用来做 DMA 相关的操作，例如 iOS 中的 JPEG 引擎以及 IOSurface transform 等模块。我们选择研究 IOSurface transform 模块的工作机制。以下是 IOSurface transform 模块的工作机制：
IOSurfaceAccelerator 接口通过用户态提供的两个 IOSurface 地址作为用户参数，通过操作 Scaler 设备，将 IOSurface 对应的地址转换成 Scaler 设备可见的设备地址，然后启动 scaler 设备进行 transform，整个过程如下：
另一方面，在这个 Host-to-device DMA 过程中，用户态内存的只读属性是否被考虑在内，是一个比较疑惑的问题。我们经过研究，发现在 IOMMU 中是支持内存属性的：
在 TTE 的第8和第9位，是用于执行内存页的读写属性的：
因此我们得到这样的页表属性定义：
我们之后介绍了苹果图形组件的工作模式：
在 iPhone7 设备中，一共有128个 Channel，这些 Channel 被分成三类：CL、GL 和 TA，内核将来自用户态的绘图指令包装并塞入这128个 channel，然后等待 GPU 的处理。由于 GPU 处理是高并发的，因此需要很健全的通知机制：
首先GPU会映射一个128个元素的 stampArray 给 kernel，kernel 也会把这块内存映射到用户态。与此同时，内核也维护了一个 stamp address array，用于保存每个 channel的stamp 地址：
值得注意的是，GPU 每处理完一个绘图指令后，都会将对应 channel 的 stamp 值加1。另一方面，对于每个绘图指令，都会有一个期望 stamp 值，这个值被封装于IOAccelEvent 对象中：
系统通过简单的比较 expectStamp 于当前 channel 的 stamp 值就可以确定这个绘图指令是否已经完成。为了提高处理效率，部分 IOAccelEvent 对象会被映射到用户态，属性只读。
在介绍完了所有这些机制性的问题后，我们来介绍两个用于 Jailbreak 的关键漏洞。漏洞1存在于 DMA 映射模块，先前提到，系统的内存属性 mapOption 会被传入底层 DART 的代码中，然而在 iOS 10 以及早期的 iOS 11 版本中，这个 mapOption 参数被下层的 DART 转换所忽略：
所有操作系统中的虚拟地址，都会被映射成 IOSpace 中允许读写的内存：
之后我们介绍第二个漏洞，这个漏洞存在于苹果图形模块中。在 IOAccelResource 对象创建过程中，一个 IOAccelClientShareRO 对象会被映射到用户态作为只读内存，这个对象包含4个 IOAccelEvent 对象：
在 IOAccelResource 对象销毁过程中，testEvent 函数会被执行，用于测试 IOAccelResource 对应的绘图指令是否已经被 GPU 处理完成：
在这个代码逻辑中，由于内核充分信任这块 IOAccelEvent 内存不会被用户态程序篡改（因为是只读映射），因此并没有对 channelIndex 做边界检查。这虽然在绝大多数情况下是安全的，但如果我们配合漏洞1，在用户态直接修改这块只读内存，就会导致可信边界被彻底破坏，从而造成 m_stampAddressArray 的越界读以及 m_inlineArray 的越界写：
最后，我们讨论两个漏洞的利用。要利用这两个漏洞并不容易，因为我们需要找到一种内存布局方法，让 m_stampAddressArray 以及 m_inlineArray 这两个数组的越界值都可控。但因为这两个数组在系统启动初期就已经分配，而且这两个数组的元素大小并不相同，因此布局并不容易。
经过研究，我们发现，只有通过指定大 index 以及合理的内核对喷，才能实现这样的布局。因为在 iPhone7 设备中，用户态应用可以喷射大概 350MB 的内存，并且在 m_stampAddressArray 以及 m_inlineArray 初始化后，会有额外50MB的内存消耗，因此我们需要使得 index 满足以下两个条件：
index ∗ 24 < 350MB + 50MB
index ∗ 8 > 50MB
也就是说 index 的值需要在[0x640000, 0x10AAAAA]这个范围内，可以使得两个数组的越界值极大概率在我们可控的喷射内存内：
然后，下一个问题就是，我们是否能够任意地址读以及任意地址写。对于任意地址读似乎不是什么问题，因为 m_stampAddressArray 的元素大小是8字节，可以通过指定任意 index 到达任意内存地址。但任意地址写需要研究，因为 m_inlineArray 的元素大小是24字节，只有一个 field 可以用于越界写，所以不是每个内存地址都可以被写到：
在这种情况下，我们退求其次，如果能实现对于一个页中的任意偏移值进行写操作，那么也可以基本达到我们的要求。在这里，我们需要通过同余定理来实现：
因为：
0xc000 ≡ 0(mod0x4000)
因此对于任意整数n，满足：
n ∗ 0x800 ∗ 24 ≡ 0(mod0x4000)
由于0x4000 / 24 * 0xF0 / 16 = 0x27f6，我们得到：
0xF0 + 0x27f6 ∗ 24 + n ∗ 0x800 ∗ 24 ≡ 0(mod0x4000)
最后我们得出结论，如果需要通过越界m_inlineArray写到一个页的前8字节，需要满足:
index = 0x27f6 + n ∗ 0x800
而如果需要到达任意页内偏移，假设要到达偏移m，则index需要满足条件：
index = 0x27f6 + 0x2ab ∗ m/8 + n ∗ 0x800
与之前得出的 index 范围结论相结合，我们最终选择了 index 值0x9e6185:
然后我们通过以下几个步骤进行漏洞利用，在第一个布局中，我们得出Slot B与Slot C的index值：
随之我们将 slot B 填入相同大小的 AGXGLContext 对象，然后再次利用漏洞泄露出其 vtable 的第四位：
最后我们通过将 Slot C 释放并填入 AGXGLContext 对象，将其原本0x568偏移的AGXAccelerator 对象改为我们可控的内存值，实现代码执行：
最后，整个利用流程总结如下：
在通过一系列 ROP 后，我们最终拿到了 TFP0，但这离越狱还有一段距离：绕过 AMFI，rootfs 的读写挂载、AMCC/KPP 绕过工作都需要做，由于这些绕过技术都有公开资料可以查询，我们这里不作详细讨论：
最后，我们对整条攻击链作了总结：
在iOS 11的第一个版本发布后，我们的DMA映射漏洞被修复；
但是苹果图形组件中的越界写漏洞并没有被修复；
这是一个”设计安全，但实现并不安全”的典型案例，通过这一系列问题，我们将这些问题串联起来实现了复杂的攻击；
也许目前即便越界写漏洞不修复，我们也无法破坏重新建立起来的只读内存可信边界；
但是至少，我们通过这篇文章，证明了可信边界是可以被打破的，因为用户态只读映射是”危险”的；
也许在未来的某一天，另一个漏洞的发现又彻底破坏了这样的可信边界，配合这个越界写漏洞将整个攻击链再次复活。这是完全有可能的。
对 iOS 安全研究感兴趣的朋友可以查看此次议题发布的白皮书《KeenLab iOS越狱细节揭秘：危险的用户态只读内存》获取更多信息。