BlackHat 2018 | iOS越狱细节揭秘：危险的用户态只读内存

议题概要

现代操作系统基本都已经在硬件级别(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对象会被映射到用户态，属性只读。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!