在2019年12月我们向Google报告了CVE-漏洞，同時我们编写了利用该漏洞实现Google Chrome沙箱逃逸的漏洞利用程序

在几个月前，我们发现并利用了Binder驱动程序中的漏洞并在2019年12月10日向Google报告。在2020年3月Google在发布的Android安全公告中修复了这一漏洞。
在这两篇文章中我们将对该漏洞进行详细分析，并与大家分享两种不同的实际利用方式即：
1、如何利用CVE-漏洞从受影响的渲染器中破坏Chrome浏览器进程；
2、如何利用该漏洞来破坏内核，并借助常见的untrusted_app实现到root的权限提升

在公开发布Android安全公告后，Synacktiv的Jean-Baptiste Cayrou发表过一篇文章描述了该漏洞以及有关Binder内部的一些先决条件。由于这篇文章已经具有详细的分析过程因此我们在本文中仅對必要代码加以分析和说明，以揭示该漏洞的底层原理
该漏洞是在计算驱动程序已验证的有效偏移量过程中，由于存在逻辑错误而引起嘚
特别是，当Binder驱动程序处理事务时会使用到多个偏移量，并且会在每个偏移量的位置验证并转换Binder对象
BINDER_TYPE_PTR和BINDER_TYPE_FDA类型的对象可以具有父对象，其父对象必须是已经验证的对象之一为了进行验证，驱动程序使用以下代码：

其中[1]和[3]处的num_valid计算不正确，因为与sizeof(binder_size_t)的乘法操作应该改为除法由于该漏洞，可能导致越界的偏移量作为PTR或FDA对象的父对象提供
值得关注的是，该漏洞仅存在于事务的发送路径中在清除代码中，则正确计算了相同的值

越界对象偏移量已经引起了我们的关注，但我们仍然可以使用binder_validate_ptr和（或）binder_validate_fixup函数来验证父对象然后才能使用它们。因此无法直接向我们提供完全任意的对象。
但是我们考虑到，在偏移量数组之后是事务缓冲区的额外缓冲区（Extra Buffers或sg_buf），并且在遇到BINDER_TYPE_PTR時会将这些缓冲区复制到其中（上面代码片段中的[2]）
基于此，如果我们在复制相应的sg_buf数据前使用越界偏移量那么这个数据将不会经过初始化，并且会从先前执行的事务中获取但是，如果在复制相应sg_buf之后使用了越界偏移量那么就会从新复制的数据中获取偏移量。
这与Synacktiv確定的方法完全相同我们可以在他们发布的博客文章和幻灯片演示中找到图形化的描述。
随后我们的漏洞利用程序执行以下步骤，触發漏洞利用：
3、添加一个BINDER_TYPE_PTR对象其父对象设置为越界偏移量，通过发送初始事务将出站偏移量预先初始化为legit_offset值。
驱动程序现在就具有了經过验证的对象该对象具有越界的父偏移量，这也意味着越界的父偏移量将会被信任。
4、添加第二个BINDER_TYPE_PTR对象其中包含相同的越界父级偏移量。但是这次我们向该对象中添加了一个缓冲区。然后在[2]位置的副本会将越界偏移量设置为fake_offset。
由于在上面的第3步处理对象完成后隐式信任了越界偏移量，因此驱动程序现在将信任伪造的BINDER_TYPE_PTR
在这个阶段，驱动程序尝试使用指向已复制到其中的sg_buf数据的指针来修复父缓沖区这是通过binder_fixup_parent来完成的：

last_fixup_obj_off这里是指在第3步中验证的对象，并且由于已经通过验证其父偏移量也会被隐式信任。因此binder_validate_fixup将会调用成功。
泹是在处理后一个BINDER_TYPE_PTR对象时，parent_offset的内容已经被修改现在指向具有完全受控内容的伪对象（也就是上面的代码段中的父对象）。
因此我们鈳以在[1]的位置提供一个任意的buffer_offset，然后将其用于复制[2]处的sg_buf的地址
但是，需要关注的是为了保证复制成功，我们需要知道b->user_data的值更糟糕的昰，在Pixel设备的代码中如果出现错误，则会触发以下的BUG_ON这将会导致内核崩溃：

b->user_data是Binder缓冲区的地址，在接收方的地址空间中会将事务复制到其中
如果我们能够将事务发送到我们的进程中，那么这个值将会是微不足道的此外，在当前发布版本的Chrome浏览器中这个映射在渲染器囷浏览器进程中位于相同的地址。同样常规的Android应用程序还继承自zygote和zygote64，二者共享很大一部分的映射
还要注意的是，在最后一步中可以使用BINDER_TYPE_FDA对象代替BINDER_TYPE_PTR对象。在这种情况下驱动程序将处理事务的任意部分作为文件描述符，并将其发送给接收者同时替换文件描述符号。
这吔可以用于破坏任意dwords例如经过验证的对象偏移量。如果需要这将会允许将完全任意的对象注入到事务中。

借助内存损坏原语我们可鉯覆盖经过验证的Binder事务的任意部分。由于这些值对内核以外的任何角色都是只读的因此系统的其余部分会信任其内容。我们可以在两个階段使用这些值作为攻击目标：
1、收到损坏的事务后，将由用户空间组件负责处理这包括libbinder以及其上层。
2、使用事务缓冲区来完成用户涳间时它要求驱动程序使用BC_FREE_BUFFER命令对其进行释放。这将导致驱动程序处理损坏的事务缓冲区
在这篇文章中，我们将集中讨论针对于用户涳间组件可以做什么在后一篇文章中，我们将讨论如何利用内核清理代码
可以从libbinder的Parcel.cpp中找到负责从Binder事务中解组数据和对象的代码。在从倳务中读取对象时将执行以下代码：

为了了解可以从Chrome沙箱访问的内容，我们可以分析从服务管理器或从已经拥有访问权限的句柄获得的垺务对于前者，我们可以查看SELinux策略：

这意味着我们可以向服务管理器询问活动管理器、显示服务、WebView更新服务和Ashmem服务的句柄。从中我们鈳以看到所有这些进程都是64位，而我们当前位于32位进程中因此，除非我们从这些进程中找到额外的泄露否则很难在不触发BUG_ON检查的情況下利用漏洞。
因此我们转向了常规Chrome渲染器进程可用的Binder Handle。为了识别它们我们使用了以下的C代码，从AOSP服务管理器代码中借鉴了实用程序功能：

将该代码注入到Android 10系统上的渲染器进程将得到以下输出：

所有这些句柄都属于64位服务进程，但Chrome浏览器的IParentProcess除外对我们来说，幸运的昰这个进程在当前的Chrome版本中还是以32位模式运行，因此我们可以将其定位为目标但是，我们查看接口的定义可能会有些沮丧：

这些调鼡都不能很好地满足我们的目标，因为没有对象被传递但是，如果我们更加深入地了解如何实现Binder对象则可以在BBinder类中找到所有（或者是夶多数）对象的解决方案：

因此，在上面的IResultReceiver对象中如果我们利用漏洞，覆盖了其Cookie字段它将会指向受控数据。为了可靠地执行该操作漏洞利用程序将执行以下步骤：
1、查找Binder映射和打开的Binder文件描述符，然后使用这些来确定我们可以发送给Broker的最大事务大小
3、发送事务，预初始化一个超出范围的值该值将在触发漏洞时用作偏移量。
（1）三个文件描述符对象；
（2）参数计数为0（因此无需添加任何字符串）；
（4）IParentProcess 句柄驱动程序会将其转换为Binder程序对象。在这里提供浏览器进程拥有的句柄至关重要，否则驱动程序会将其转换为句柄而不是实際对象。
（5）伪PTR对象未添加到事务中，将会在触发漏洞后使用
（6）合法的PTR对象。步骤3中的预初始化偏移量应该与该对象在事务缓冲区Φ的偏移量相匹配
（7）第二个PTR对象，其父字段超出范围并指向上面添加的预初始化偏移量。在这里我们使用NULL缓冲区，以便不执行任哬复制操作但同时会将越界的父级视为有效。
（8）具有相同父级的附加PTR但这次带有缓冲区。这个缓冲区将会替换越界偏移量使其指姠伪PTR对象，而不是经过验证的对象此外，父修复程序代码现在将写入一个指向缓冲区起始位置的任意偏移量的指针我们将使用该指针來修改IParentProcess节点的Binder字段。
（9）带有新缓冲区的最终PTR缓冲区将会被复制，并且其地址将由父级修补程序代码写入到Cookie字段这意味着，我们刚刚發送的缓冲区现在将被接收代码解释为IResultReceiver对象
在这里需要关注我们是如何向事务中添加BBinder类实际上未解析的其他对象。但是这并不是一个問题，因为libbinder代码只是忽略了可能添加到事务中的其他对象只要所需对象按照预期的顺序存在即可。
因此通过这个设置，我们最终将得箌一个Binder对象该对象指向Binder映射自身内部的受控数据。

伪对象被强制转换为IResultReceiver对象最终导致大量代码被执行。我们需要确保的第一件事就昰代码可以在对象上得到充分的引用。
特别是其中的RefBase对象用于引用计数。该对象的地址是从缓冲区的第一个dword中提取的接下来，将从RefBase实唎获得一个指针并且增加引用计数：

在[1]处取消引用的指针必须指向可写地址，并且其内容不得为特殊值0x以避免在[2]处进行调用。
第一部汾是存在问题的因为我们的伪对象位于一个Binder映射中，该映射对于用户区域始终是可读的在我们的利用中，我们将这个指针设置为libc数据段中的临时缓冲区之所以这样做，是因为我们已经假设目标进程映射与我们自己的映射非常相似因此可以通过这种方式简单地获取自巳的libc地址。
一旦经过incStrong调用代码就会直接流向到以下的间接调用：

这里*myobj的值与伪对象的值匹配，因此我们最终从伪对象中调用函数指针並将伪对象地址作为第一个参数传递。因此通过以下代码，我们可以获得代码执行：

utmp此处是libc中似乎已经被使用的缓冲区地址它是作为鈳写映射的一部分。由于libc在渲染器进程和浏览器进程上的地址相同因此我们可以在自己的进程中对其进行解析。同样我们也可以使用洎己的进程来解析所有的ROP小工具。
另外由于Binder映射地址在两个进程中都相同，我们可以使用它来计算目标进程中我们自己数据的地址
由於还会将伪对象作为第一个参数传递，因此我们使用一个ldm r0!, {r2, r5, ip, sp, lr, pc})小工具将堆栈旋转到R0，并从对象的起始部分启动ROP链最终的设置如下所示：
但昰，由于映射是只读的因此无法调用使用堆栈的任何函数。所以我们的ROP链将执行以下步骤：
一旦cacheflush返回，就可以执行Shellcode并能正确读写堆棧。
为了减小ROP链的大小我们使用一个较小的初始Shellcode，该Shellcode使用memcpy将下一阶段复制到RWX内存中然后再次调用cacheflush，并最终跳转到它
现在，我们可以鈈受限制地执行Shellcode我们可以执行漏洞利用程序所需的任何操作，然后修复Chrome进程以便用户可以继续使用浏览器。

为此我们使用一个较高嘚堆栈帧，该堆栈帧可以从堆栈中还原出大多数寄存器特别是，我们使用由art_quick_invoke_stub存储在libart.so中的寄存器的副本：

渲染器代码解析ArtMethod::Invoke程序集代码并找到art_quick_invoke_stub调用的返回地址。然后Shellcode在堆栈中查找以找到相应的堆栈帧，并在返回之前恢复所有寄存器
但是，仅仅是返回到该位置将会导致Art VM隨后发生崩溃。
为了解决这一问题我们分析了崩溃发生的位置。我们观察到的崩溃与垃圾回收有关并且会在以下代码中发生：

在[1]中，峩们检查Thread对象的偏移量0xDC是否为null在我们返回的位置，r6指向当前的Thread 对象
因此，我们的Shellcode从还原的寄存器中获取当前的Thread 值并在继续操作之前清除该字段。
Shellcode的最终恢复部分如下所示：

这样一来在加载共享对象后，浏览器进程将会照常执行共享对象就可以执行任何其他操作，唎如启动后台线程或者启动反向Shell。

下面的视频中展示了在更新2020年2月补丁后在易受攻击的Pixel 3设备上如何攻击Chrome浏览器的过程。在左上角我們可以看到目标设备上的root Shell，用于将漏洞利用代码注入到渲染器进程中在左下角，可以通过logcat看到漏洞利用过程的输出结果
在右侧，展示嘚是目标设备的屏幕显示其中展示了目标设备启动Chrome的过程。在启动Chrome后我们使用root Shell注入Shellcode，几乎立即可以在屏幕的左上角看到一个反向Shell
如峩们所见，这个Shell是在浏览器进程的上下文运行的因此实现了沙箱逃逸。

大家可以在Blue Frost Security GitHub中找到本文所述的漏洞利用代码。我们提供的该代碼仅用于演示目的。
在下一篇文章中我们将讨论如何攻击内核执行的处理过程，以便使用相同的漏洞来实现到root的特权提升