在文中中，大家将为阅读者深层次详细介绍Binder中的单指令竞态标准漏洞以及利用方式。

在上年10月份的安卓系统安全性公示中，漏洞CVE-2020-0423被公布，实际叙述以下:

在binder.c的binder_release_work中，因为上锁不善，造成 UAF漏洞。这很有可能造成 核心中的当地提权漏洞，而不用附加的实行管理权限。而且，利用该漏洞时不用客户互动。

CVE-2020-0423是Android中另一个可造成 管理权限提高的漏洞。在本文中，大家将详细分析这一漏洞，并结构一个可用以在Android机器设备上获得root管理权限的exploit。

Android上的进程全是相互之间防护的，换句话说，他们没法立即浏览彼此之间的存储空间。殊不知，有时他们却必须那样做，比如，不论是在远程服务器和集群服务器互换数据信息，還是只是在2个进程中间共享资源信息内容的情况下。

Android上的进程间通信由Binder承担的。该核心部件出示了一个客户可浏览的标识符机器设备，可用以调用远程控制进程中的 *** ，并向其传送主要参数。事实上，Binder不但当做了2个每日任务中间的 *** 商，还承担在数据传输期内解决内存分配及其管理 *** 共享资源目标的生命期的每日任务。

假如您不了解Binder的内部构造，何不先参考这些方面的一些文章内容，比如Synacktiv编写的“Binder Transactions In The Bowels of the Linux Kernel”，这针对了解本文的一部分会很有协助。

CVE-2020-0423的补丁程序于10月10日upstream至Linux核心，并含有下列递交信息：

上边的文本粗略地简述了利用这一漏洞开启Use-After-Free或UAF漏洞需要的不一样流程。这种流程将在下一节中详尽多方面详细介绍，如今使我们先讨论一下补丁程序，以掌握漏洞的根本原因在哪儿。

实质上，这一补丁下载所做的事儿便是将涵数binder_dequeue_work_head的內容内联到binder_release_work涵数中。唯一的差别是，在依然对proc上锁的另外，载入binder_work结构体的type字段名。

// Before the patch

static struct binder_work *binder_dequeue_work_head(

struct binder_proc *proc,

struct list_head *list)

{

struct binder_work *w;

binder_inner_proc_lock(proc);

w=binder_dequeue_work_head_ilocked(list);

binder_inner_proc_unlock(proc);

return w;

}

static void binder_release_work(struct binder_proc *proc,

struct list_head *list)

{

struct binder_work *w;

while (1){

w=binder_dequeue_work_head(proc, list);

if (!w)

return;

switch (w->type){

//[...]

// After the patch

static void binder_release_work(struct binder_proc *proc,

struct list_head *list)

{

struct binder_work *w;

enum binder_work_type wtype;

while (1){

binder_inner_proc_lock(proc);

w=binder_dequeue_work_head_ilocked(list);

wtype=w ? w->type : 0;

binder_inner_proc_unlock(proc);

if (!w)

return;

switch (wtype){

//[...]

在这个补丁下载以前，能够让一个binder_work结构体撤出序列，释放出来另一个线程并分配，随后变更binder_release_work的控制流。下一节中，大家将更深层次地表述怎么会产生这类个人行为，及其它是怎样被随意开启的。

在这节中，做为一个实例，使我们想像有两个进程应用binder开展通讯，在其中，一个进程为推送方，另一个进程为接受方。

这时，开启该漏洞必须三个前提条件：

从推送方线程调用binder_release_work

从推送方线程的todo目录中出列的binder_work结构体

从接受方线程中释放出来的一个binder_work结构体

使我们逐一开展科学研究，并试着找到完成他们的方式。

完成这一必要条件比较简单。如前所述，当应用binder解决每日任务时，binder_release_work是清除 *** 的一部分。我们可以应用ioctl指令binder_thread_exit在线程中显式调用它。

// Userland code from the exploit

int binder_fd=open("/dev/binder", O_RDWR);

//[...]

ioctl(binder_fd, BINDER_THREAD_EXIT, 0);

这一ioctl最后将调用坐落于drivers/android/binder.c文档中的核心涵数binder_ioctl。

随后，binder_ioctl将抵达BINDER_THREAD_EXIT支系，并调用binder_thread_release涵数。在其中，thread是一个binder_thread结构体，储存当今开展ioctl调用的线程的信息内容。

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)

{

//[...]

case BINDER_THREAD_EXIT:

binder_debug(BINDER_DEBUG_THREADS, "%d:%d exit

",

proc->pid, thread->pid);

binder_thread_release(proc, thread);

thread=NULL;

break;

//[...]

在binder_thread_release涵数的尾端，发生了对binder_release_work涵数的调用。

static int binder_thread_release(struct binder_proc *proc,

struct binder_thread *thread)

{

//[...]

binder_release_work(proc, &thread->todo);

binder_thread_dec_tmpref(thread);

return active_transactions;

}

一定要注意，在调用bind_release_work时，主要参数list_head *list的数值&thread->todo。在我们试着用binder_work结构体添充该目录时，将涉及到一二节的內容。

static void binder_release_work(struct binder_proc *proc,

struct list_head *list)

{

struct binder_work *w;

while (1){

w=binder_dequeue_work_head(proc, list);

if (!w)

return;

//[...]

即然大家知道怎样开启易受攻击的涵数，那麼使我们来明确怎样用随意的binder_work结构体来添充线程的TODO目录。

binder_work结构体被安插到thread->todo的2个部位处：

binder_enqueue_deferred_thread_work_ilocked

static void

binder_enqueue_deferred_thread_work_ilocked(struct binder_thread *thread,

struct binder_work *work)

{

binder_enqueue_work_ilocked(work, &thread->todo);

}

binder_enqueue_thread_work_ilocked

static void

binder_enqueue_thread_work_ilocked(struct binder_thread *thread,

struct binder_work *work)

{

binder_enqueue_work_ilocked(work, &thread->todo);

thread->process_todo=true;

}

这种涵数在编码中的不一样地区都是有采用，可是大家很感兴趣的编码途径是以binder_translate_binder逐渐的那一个。当线程发送包含BINDER_TYPE_BINDER或BINDER_TYPE_WEAK_BINDER的事务时将调用该函数。

　　之后，从binder对象创建一个binder节点，并令接收端进程的引用计数器加1。只要接收进程持有对该节点的引用，它就会在Binder的内存中保持活动状态。但是，如果进程释放该引用，那么该节点将被销毁，这也是我们稍后将尝试实现的触发UAF的功能。

　　首先，让我们解释一下在调用binder_inc_ref_for_node的过程中，binder节点和thread -> todo列表的关系。

　　static int binder_translate_binder(struct flat_binder_object *fp,

　　struct binder_transaction *t,

　　struct binder_thread *thread)

　　{

　　// [...]

　　ret=binder_inc_ref_for_node(target_proc, node,

　　fp->hdr.type==BINDER_TYPE_BINDER,

　　&thread->todo, &rdata);

　　// [...]

　　}

　　binding_inc_ref_for_node的参数如下所示：

　　structinder_proc * proc：保存对节点的引用的进程

　　struct binder_node * node：目标节点

　　bool strong：true=强引用，false=弱引用

　　struct list_head * target_list：如果节点增加，则使用的工作列表

　　struct binder_ref_data * rdata：引用的ID/引用计数数据

　　当前路径中的target_list是thread->todo。该参数仅在调用binder_inc_ref_olocked的binder_inc_ref_for_node中使用。

　　static int binder_inc_ref_for_node(struct binder_proc *proc,

　　struct binder_node *node,

　　bool strong,

　　struct list_head *target_list,

　　struct binder_ref_data *rdata)

　　{

　　// [...]

　　ret=binder_inc_ref_olocked(ref, strong, target_list);

　　// [...]

　　}

　　然后，binder_inc_ref_olocked会调用binder_inc_node，不管它是弱引用还是强引用。

　　static int binder_inc_ref_olocked(struct binder_ref *ref, int strong,

　　struct list_head *target_list)

　　{

　　// [...]

　　// Strong ref path

　　ret=binder_inc_node(ref->node, 1, 1, target_list);

　　// [...]

　　// Weak ref path

　　ret=binder_inc_node(ref->node, 0, 1, target_list);

　　// [...]

　　}

　　binder_inc_node是binder_inc_node_nilocked的一个简单封装器，它在当前节点上持有一个锁。

　　binder_inc_node_nilocked最后将调用：

　　binder_enqueue_deferred_thread_work_ilocked，如果节点上有一个强引用的话；

　　binder_enqueue_work_ilocked，如果节点上有弱引用的话。

　　在实践中，引用是弱是强都无关紧要。

　　static int binder_inc_node_nilocked(struct binder_node *node, int strong,

　　int internal,

　　struct list_head *target_list)

　　{

　　// [...]

　　if (strong) {

　　// [...]

　　if (!node->has_strong_ref && target_list) {

　　// [...]

　　binder_enqueue_deferred_thread_work_ilocked(thread,

　　&node->work);

　　}

　　} else {

　　// [...]

　　if (!node->has_weak_ref && list_empty(&node->work.entry)) {

　　// [...]

　　binder_enqueue_work_ilocked(&node->work, target_list);

　　}

　　}

　　return 0;

　　}

　　这里需要注意的是，实际上是node->work字段被被安插在thread->todo列表中，因此，它并不是普通的binder_work结构体。这是因为binder_node嵌入了一个binder_work结构体。这意味着，要触发这个漏洞，我们要释放的不是一个单独的binder_work结构体，而是要释放整个binder_node。

　　到目前为止，我们介绍了如何填充thread->todo列表，以及如何调用易受攻击的函数binder_release_work来访问可能被释放的binder_work/binder_node结构体。剩下的唯一一步就是想办法释放我们在线程中分配的binder_node。

　　在本系列文章中，我们将为读者深入介绍Binder中的单指令竞态条件漏洞及其利用 *** 。由于篇幅过长，我们将分多篇文章发表，更多精彩内容，敬请期待！

　　（未完待续）