CVE-2019-9213——linux内核用户空间0虚拟地址映射漏洞分析

0x00 漏洞原理

前一段时间project zero的jann horn披露了一个 linux 内核用户空间0虚拟地址映射漏洞，通过这个漏洞可以绕过mmap_min_addr的限制，再配合一个内核中的null pointer dereference漏洞理论上有提权的可能。这个漏洞是非常有趣的，这里分享一下我的分析。

POC很短，我们直接来看POC：

触发漏洞的点在于LD_DEBUG=help su 1>&%d向/proc/self/mem中写入了数据，其实LD_DEBUG=help su并不重要，重要的是通过它调用write函数。下面我们就来一步一步分析从这行代码到漏洞点的过程。

linux内核对于文件系统通用的结构体是file_operations，fs/proc/base.c中的代码提供与/proc相关的操作。

LD_DEBUG=help su 1>&%d会调用write函数，在这里也就是mem_write函数。mem_write函数是对mem_rw函数的封装。

在while循环中，如果是写首先通过copy_from_user函数将待写内容buf拷贝到分配的page中，然后调用access_remote_vm函数写入远程进程。读则相反，先调用access_remote_vm函数读取远程进程中的数据，然后调用copy_to_user函数将读取的page拷贝到buf中。

access_remote_vm函数是对__access_remote_vm函数的封装(这里注意分析mmap.c中的代码，nommu.c中的代码是用在没有MMU的CPU上的)。

在__access_remote_vm函数的while循环中调用get_user_pages_remote函数，get_user_pages_remote函数和get_user_pages函数都是对__get_user_pages_locked函数的封装，作用在于查找并将给定的虚拟地址范围固定到page。之后通过kmap函数将page映射到永久内存映射区，如果是写操作则调用copy_to_user_page函数之后调用set_page_dirty_lock函数将page设置为脏，读操作则调用copy_from_user_page函数。之后调用kunmap函数取消映射。

get_user_pages_remote函数和get_user_pages函数的区别在于是否跨进程。get_user_pages_remote函数调用__get_user_pages_locked函数时设置了FOLL_REMOTE标志区分。

__get_user_pages_locked函数在for循环中首先调用__get_user_pages函数将start 开始的nr_pages个页固定到pages，返回成功固定的页的个数。

__get_user_pages函数首先查找vma，调用follow_page_mask函数查询页表获取虚拟地址对应的物理页，如果返回null会调用faultin_page函数。获取到page的指针之后存在pages数组中。

__get_user_pages函数返回值大于0说明调用成功，减少nr_pages增加pages_done，nr_pages为0则退出循环。

再固定一个页，正常情况下应该返回0退出循环，如果没有退出循环nr_pages减1，pages_done加1，start地址加一个PAGE_SIZE重新开始固定。

__get_user_pages函数查找vma是通过调用find_extend_vma函数实现的，如果vma->vm_start <= addr说明addr在VMA空间范围内；否则说明addr落在空洞中。如果设置了VM_GROWSDOWN标志位调用expand_stack函数扩展vma。

expand_stack函数是对expand_downwards函数的封装。

expand_downwards函数中做的首先就是调用security_mmap_addr函数检查权限。

security_mmap_addr函数是对cap_mmap_addr函数的封装。

终于来到了漏洞点，cap_mmap_addr函数中检查的是current_cred()，是执行write操作的进程的cred而不是vma被改变的进程的cred。在POC中是通过system函数调用LD_DEBUG=help su 1>&%d命令执行的write操作，当然是另外一个进程。

完整调用链：mem_write -> mem_rw -> access_remote_vm -> __access_remote_vm -> get_user_pages_remote -> __get_user_pages_locked -> __get_user_pages -> find_extend_vma -> expand_stack -> expand_downwards -> security_mmap_addr -> cap_mmap_addr

POC执行效果如下。

0x01 补丁情况

补丁也是由jann horn提供的，expand_downwards函数不再调用security_mmap_addr函数了，直接和mmap_min_addr比较。

笔者以为这样修补没有真正解决问题。这是一个逻辑漏洞，根本原因在于可以通过两个进程绕过security_mmap_addr函数中cap_capable(current_cred()……)的检查逻辑，补丁只是在expand_downwards函数中不再调用security_mmap_addr函数了，是否存在其它调用security_mmap_addr的函数？当然存在，但是笔者大致翻看了一下，似乎只有get_user_pages_remote函数才能够跨进程调用到security_mmap_addr函数(也有可能是笔者眼拙未能找到)。同样是内存管理中的逻辑问题，这个漏洞各方面来讲巧妙程度可能不亚于DirtyCow，唯一遗憾的在于不能直接提权，显得鸡肋了。

0x02 时间线

2019-03-06 漏洞公开

2019-03-14 360CERT发布分析报告

0x03 参考链接

1. https://bugs.chromium.org/p/project-zero/issues/detail?id=1792
2. Dirty COW and why lying is bad even if you are the Linux kernel