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


QQ代刷网

发表评论 取消回复

电子邮件地址不会被公开。 必填项已用*标注