linux “大脏牛”漏洞分析(CVE-2017-1000405)

冷不防 2021-07-28 23:51 935阅读 0赞

### 一、背景简介 ###

脏牛漏洞(CVE-2016–5195)是公开后影响范围最广和最深的漏洞之一，这十年来的每一个Linux版本，包括Android、桌面版和服务器版都受到其影响。恶意攻击者通过该漏洞可以轻易地绕过常用的漏洞防御方法，对几百万的用户进行攻击。尽管已针对该漏洞进行了补丁修复，但国外安全公司Bindecy对该补丁和内容做出深入研究后发现，脏牛漏洞的修复补丁仍存在缺陷，由此产生了“大脏牛”漏洞。基于多年以来针对移动端漏洞的技术积累和安全对抗，安天移动安全对“大脏牛”漏洞进行了详细的技术分析，并提供了验证方案，全文如下。

### 二、漏洞原理分析 ###

**2.1 脏牛漏洞回顾**

在分析大脏牛漏洞前，我们需要对原始的脏牛漏洞利用方式进行完整的分析理解： 之前的漏洞是在`get_user_pages`函数中，这个函数能够获取用户进程调用的虚拟地址之后的物理地址，调用者需要声明它想要执行的具体操作(例如写/锁等操作)，所以内存管理可以准备相对应的内存页。具体来说，也就是当进行写入私有映射的内存页时，会经过一个COW(写时拷贝)的过程，即复制只读页生成一个带有写权限的新页，原始页可能是私有保护不可写的，但它可以被其他进程映射使用。用户也可以在COW后的新页中修改内容之后重新写入到磁盘中。

现在我们来具体看下`get_user_pages`函数的相关代码：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70][]

整个while循环的目的是获取请求页队列中的每个页，反复操作直到满足构建所有内存映射的需求，这也是retry标签的作用。

`follow_page_mask`读取页表来获取指定地址的物理页(同时通过PTE允许)或获取不满足需求的请求内容。在`follow_page_mask`操作中会获取PTE的spinlock，用来保护试图获取内容的物理页不会被释放掉。

`faultin_page`函数申请内存管理的权限(同样有PTE的spinlock保护)来处理目标地址中的错误信息。在成功调用faultin\_page后，锁会自动释放，从而保证`follow_page_mask`能够成功进行下一次尝试，以下是涉及到的代码。

原始的漏洞代码在`faultin_page`底部：

![20191016142426820.png][]

上面这个判断语句想要表示的是，如果当前VMA中的标志显示当前页不可写，但是用户又执行了页的写操作，那么内核会执行COW操作，并且在处理中会有VM\_FAULT\_WRITE标志。换句话说在执行了COW操作后，上面的if判断为真，这时就移除了FOLL\_WRITE标志。

一般情况下在COW操作后移除`FOLL_WRITE`标志是没有问题的，因为这时VMA指向的页是刚经过写时拷贝复制的新页，我们是有写权限的，后续不进行写权限检查并不会有问题。 但是，考虑这样一种情况，如果在这个时候用户通过madvise(MADV\_DONTNEED)将刚刚申请的新页丢弃掉，那这时本来在`faultin_page`后应该成功的`follow_page_mask`会再次失败，又会进入`faultin_page`的逻辑，但是这个时候已经没有`FOLL_WRITE`的权限检查了，只会检查可读性。这时内核就会将只读页面直接映射到我们的进程空间里，这时VMA指向的页不再是通过COW获得的页，而是文件的原始页，这就获得了任意写文件的能力。

基本来看，上述的过程流也就是脏牛漏洞的利用过程。

在faultin\_page中有对应的修复补丁：

![20191016142452392.png][]

同时也加入了另一个新的`follow_page_mask`函数：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 1][]

与减少权限请求数不同，`get_user_pages`现在记住了经过COW循环的过程。之后只需要有`FOLL_FORCE`和`FOLL_COW`标志声明过且PTE标记为污染，就可以获取只读页的写入操作。

**2.2 大脏牛漏洞分析**

THP通过PMD(Pages Medium目录，PTE文件下一级)的`_PAGE_PSE`设置来打开,PMD指向一个2MB的内存页而非PTEs目录。PMDs在每一次扫描到页表时都会通过`pmd_trans_huge`函数进行检查,所以我们可以通过观察PMD指向pfn还是PTEs目录来判断是否可以聚合。在一些结构中，大PUDs(上一级目录)同样存在，这会导致产生1GB的页。 仔细查看脏牛补丁中关于THP的部分，我们可以发现大PMDs中用了和`can_follow_write_pte`同样的逻辑，其添加的对应函数`can_follow_write_pmd`：

![20191016142530292.png][]

然而在大PMD中，一个页可以通过touch\_pmd函数，无需COW循环就标记为dirty：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 2][]

这个函数在每次`get_user_pages`调用`follow_page_mask`试图访问大页面时被调用，很明显这个注释有问题，而现在dirty bit并非无意义的，尤其是在使用`get_user_pages`来读取大页时，这个页会无需经过COW循环而标记为dirty，使得`can_follow_write_pmd`的逻辑发生错误。

在此时, 如何利用该漏洞就很明显了，我们可以使用类似脏牛的方法。这次在我们丢弃复制的内存页后，必须触发两次page fault，第一次创建它，第二次写入dirty bit。

调用链：

![20191016142548561.png][]

经过这个过程可以获得一个标记为脏的页面，并且是未COW的，剩下的就是要获取FOLL\_FORCE和FOLL\_COW标志了。这个过程可以采取类似dirtyCOW的利用方式。

总结这个漏洞利用的思路如下：

1.  首先经过COW循环，获取到FOLL\_COW标志
2.  用madvise干掉脏页
3.  再次获取页将直接标记为脏
4.  写入

### 三、影响范围 ###

3.1 漏洞影响范围

由于从2.6.38内核后才开始支持THP，所以漏洞影响所有内核在2.6.38以上并且开启THP的Linux系统。万幸的是在大多数Android系统的内核中没有开启THP，所以对于Android系统几乎没有影响。

3.2 如何在系统上查看是否受到影响

如果是开发者,有内核源码可以查看编译的config文件，看CONFIG\_TRANSPARENT\_HUGEPAGE是否打开

![20191016142604541.png][]

如果没有源码,在shell中可以查看/sys/kernel/mm/transparent\_hugepage/enabled,如果输出结果为\[always\]表示透明大页被启用、\[never\]表示透明大页被禁用、\[madvise\]表示只在MADV\_HUGEPAGE标志的VMA中启用THP，例如：

![20191016142616489.png][]

如果以上两者都没有，可以查看/proc/meminfo，如果连HugePage\*都没有，那就说明没有开启大页面，也不会受到漏洞影响。

### 四、验证代码 ###

验证POC请参照：[https://github.com/bindecy/HugeDirtyCowPOC][https_github.com_bindecy_HugeDirtyCowPOC]

### 五、修复建议 ###

截止到文章发布时间，Linux各发行版本还未公布针对该漏洞的补丁信息，软件开发人员可通过：[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=7031ae2ab37d3df53c4a4e9903329a5d38c745ec][https_git.kernel.org_pub_scm_linux_kernel_git_stable_linux-stable.git_commit_h_linux-4.9.y_id_7031ae2ab37d3df53c4a4e9903329a5d38c745ec] 新编译Linux修复该漏洞。如果开发人员暂时无法编译和替换内核，可以通过关闭透明大页（THP）来缓解。

### 六、总结 ###

“脏牛”漏洞是Linux内核之父Linus亲自修复的，他提交的补丁单独针对“脏牛”而言并没有问题。从我们的分析过程中发现，内核的开发者希望将“脏牛”的修复方法引用到PMD的逻辑中，但是由于PMD的逻辑和PTE并不完全一致才最终导致了“大脏牛”漏洞。连内核的开发者都会犯错，更何况普通的开发者。

“大脏牛”漏洞再一次提示我们，即便是官方修复过的漏洞仍有可能由修复补丁引入新的严重漏洞，漏洞在修复后需要我们像对待原始漏洞一样继续跟踪其修复补丁。

### 七、参考资料 ###

1.  [https://medium.com/bindecy/huge-dirty-cow-cve-2017-1000405-110eca132de0][https_medium.com_bindecy_huge-dirty-cow-cve-2017-1000405-110eca132de0]
2.  [https://bbs.pediy.com/thread-223056.htm][https_bbs.pediy.com_thread-223056.htm]
3.  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000405][https_cve.mitre.org_cgi-bin_cvename.cgi_name_CVE-2017-1000405]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70]: /images/20210728/7546a91334374a638063efa5670fc410.png
[20191016142426820.png]: /images/20210728/62bde2c5d4e04bee99ef8af149dde549.png
[20191016142452392.png]: /images/20210728/a66981b7175f4633bd9f7268fd9fc696.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 1]: /images/20210728/2ec17484520c46649a6cece11140bfe8.png
[20191016142530292.png]: /images/20210728/2ae93eadc39c41ebaec4e0d53e39506d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3doYXRkYXk_size_16_color_FFFFFF_t_70 2]: /images/20210728/542b60411fc24df7b8073a1af6e49317.png
[20191016142548561.png]: /images/20210728/2ad31a54112242d5b79869d3a91fcb60.png
[20191016142604541.png]: /images/20210728/ebbc4cce1e634412975d0371e38c510b.png
[20191016142616489.png]: /images/20210728/1d801b59787046ca8abddbf31c4935be.png
[https_github.com_bindecy_HugeDirtyCowPOC]: https://github.com/bindecy/HugeDirtyCowPOC
[https_git.kernel.org_pub_scm_linux_kernel_git_stable_linux-stable.git_commit_h_linux-4.9.y_id_7031ae2ab37d3df53c4a4e9903329a5d38c745ec]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=7031ae2ab37d3df53c4a4e9903329a5d38c745ec
[https_medium.com_bindecy_huge-dirty-cow-cve-2017-1000405-110eca132de0]: https://medium.com/bindecy/huge-dirty-cow-cve-2017-1000405-110eca132de0
[https_bbs.pediy.com_thread-223056.htm]: https://bbs.pediy.com/thread-223056.htm
[https_cve.mitre.org_cgi-bin_cvename.cgi_name_CVE-2017-1000405]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000405