[Android Root] CVE-2017-7533 漏洞分析和复现

[Android Root] CVE-2017-7533 漏洞分析和复现_第1张图片

本篇主要是记录一下CVE-2017-7533是什么类型的漏洞,漏洞原理是什么,以及如何触发,又是如何被patch的。进一步,编译源码刷机(此步骤耗时最为长久),在pixel2上复现。此外,进一步思考如果想要从poc到exploit进一步需要做哪些事情?


欢迎对这个漏洞感兴趣的同学一起交流学习~

0x00 漏洞原理

根据对该CVE的描述信息[1]我们可以知道,这是一个在linux kernel中fsnotify中的race condition漏洞。攻击者可以利用inotify_handle_event和vfs_rename同时执行,实现本地提权或者DoS。

Race condition in the fsnotify implementation in the Linux kernel through 4.12.4 allows local users to gain privileges or cause a denial of service (memory corruption) via a crafted application that leverages simultaneous execution of the inotify_handle_event and vfs_rename functions.


根据redhat mail[2]中对该漏洞的描述,这个漏洞由于race condition会溢出下一个slab的数据。摘录漏洞的触发过程如下图所示。

[Android Root] CVE-2017-7533 漏洞分析和复现_第2张图片


linux kernel 4.4相关代码:

[Android Root] CVE-2017-7533 漏洞分析和复现_第3张图片


inotify_event_info 结构体:

[Android Root] CVE-2017-7533 漏洞分析和复现_第4张图片


在上图中,和漏洞相关的关键点有三个:

计算file_name的len,更新alloc_len;

调用kmalloc分配alloc_len大小的内存给event指针;

调用strcpy拷贝file_name给event->name。

问题在于2和3之间,如果file_name被修改了,就可以造成heap overflow。而事实上,由于内核中有大量的线程在同时运行,file_name是可以通过sys_rename系统调用来修改的。


由于overflow的是kmalloc申请的buffer之后的内存,因此需要有效的控制该内存才可以DoS或者是提权。


0x01 漏洞影响

根据redhat mailist[2],影响的linux kernel version:v3.14-rc1 - v4.12。

对于Android而言,根据Android security bulletin[3],影响的patch level: before 2017-12-01。


0x02 漏洞分析

CVE-2017-7533这个漏洞的patch影响kernel 3.12-rc4到4.12。因此,nexus6p上是实现不了了,看了一下msm中angler的branch kernel都是3.10的。因此,在pixel 2 android 8.1 kernel 4.4上测试。通过git checkout 4.4.56-g594d847d09a1切换到对应的kernel版本。


分析漏洞原理时,我们已经明白了需要使用两个thread来触发漏洞:一个触发inotify_handle_event,一个触发sys_rename。hardenedlinux有该漏洞的POC[4]。


该POC中,main函数中的notify_thread_func线程,使用inotify机制监控test_dir/f文件的打开、关闭访问行为。如果触发了该行为,调用handle_events函数,从inotify实例中read 所有的inofity_event事件,遍历时间判断当前触发事件的event->name是否为"b",如果是,则成功触发。


main函数中的trigger_rename_open线程中又开启了两个线程,callrename和openclose。

callrename线程中构造longname "bbbb321032103210xxxxxxxx",并开始循环,循环调用两次rename系统调用,修改test_dir/f为longname再修改回来。


callrename线程比较简单,开始循环,循环打开test_dir/f,用于触发用户态中inotify_handle_event的监听事件,从而触发内核中的inotify_handle_event函数,从而竞争触发heap overflow。


漏洞触发的时候:

callrename线程中打开文件test_dir/f;

notify_thread_func线程中的监听事件被触发,调用内核的inotify_handle_event,计算file_name(test_dir/f)的len为1,kmalloc大小为sizeof(struct inotify_event_info) + len+1的buffer;

callrename线程中调用内核的sys_rename修改file_name为longname;

内核的inotify_handle_event函数调用strcpy发生堆溢出。

监听事件触发的时候read的buffer中是inotify_event结构体,其中len代表了name+padding的长度。

[Android Root] CVE-2017-7533 漏洞分析和复现_第5张图片


但是在内核中,inotify_handle_event中的event是inotify_event_info结构体,其中name_len就是代表name的长度。这个特别容易混淆。


[Android Root] CVE-2017-7533 漏洞分析和复现_第6张图片

因此,在漏洞触发时,虽然file_name已经被修改,但是内核中inotify_event_info的name_len依然还是1,name则是longname了。经过测试,用户态read的buffer中,inotify_event结构体的name似乎是根据内核中的name_len来获取的(纯属猜测),因此是漏洞触发时,用户态获取的name是b。


0x03 触发效果

1、poc运行后,输出:

[Android Root] CVE-2017-7533 漏洞分析和复现_第7张图片

图中已经检测到了event->name是b。

2、修改了kernel源码,在strcpy处加入pr_err 查看log:

[Android Root] CVE-2017-7533 漏洞分析和复现_第8张图片

3、编译内核后查看,dmesg信息:

[Android Root] CVE-2017-7533 漏洞分析和复现_第9张图片

可以看到,file_name已经被rename成了longname,strcpy给event->nam功溢出了。


0x04 漏洞修复

该漏洞在linux kernel中的patch[5]如下所示,新增加了name_snapshot结构体,并增加了dentry中name的take和release的方法。原先对dentry中name的操作都要先获取一个快照(snap)再操作。


以fsnotify.c为例:

[Android Root] CVE-2017-7533 漏洞分析和复现_第10张图片


为什么漏洞在inotify_handle_event()却要patch fsnotify(..., file_name)呢?


看了一会儿源码发现inotify_handle_event()的触发链如下:fsnotify(...,file_name)->send_to_group(... ,file_name)->group->ops->handle_event(..., file_name, cookie)。


根据ops的定义const struct fsnotify_ops *ops;,查看该结构体:


[Android Root] CVE-2017-7533 漏洞分析和复现_第11张图片


因此, group->ops->handle_event(..., file_name, cookie)是会调用inotify_handle_event()的。


patch了之后,fsnotify(..., file_name)中的file_name是snap的name,即使调用sys_rename使得dentry中的name改变了,但是fsnotify拿到的name依然没变,inotify_handle_event中也就不会发生对溢出了。


通过patch,我们可以更加清晰的发现,由于原先inotify_handle_event的file_name。

实际上是一个指向dentry中name的一个指针,在race condition时就会发生问题。漏洞的本质是传入参数的改变,那么patch 自然也应该在上层函数中patch了。

0x05 from poc to exp

写到这里,如何从poc到exp呢?其实目前我还不清楚。


既然是kmalloc发生了溢出,那么思路就是利用溢出后的数据来覆盖后面一个obj中的指针啊什么的来控制PC指针。所以溢出后面的数据是一个obj吗?如果是,这个obj可以控制吗?内核堆的管理方式又是什么样子的呢?如何查看内核堆中的数据呢?


最后,内核中这样由于竞争导致的问题肯定还有,如何发现呢?


带着这样的问题,继续上路吧。


0x06 参考链接

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7533

https://seclists.org/oss-sec/2017/q3/240

https://source.android.com/security/bulletin/2017-12-01

https://github.com/hardenedlinux/offensive_poc/tree/master/CVE-2017-7533

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49d31c2f389acfe83417083e1208422b4091cd9


- End -


[Android Root] CVE-2017-7533 漏洞分析和复现_第12张图片

看雪ID:心许雪 

https://bbs.pediy.com/user-730610.htm

本文由心许雪 原创

转载请注明来自看雪社区


长按识别下方图中的二维码,投票!

[Android Root] CVE-2017-7533 漏洞分析和复现_第13张图片



转载请注明:转自看雪学院 


更多阅读:

1、[原创]一个Android壳简单实现

2、一个简单的CrackMe破解

3、[原创]硬件断点和原理与实现

4、[原创]dex vmp虚拟化

你可能感兴趣的:([Android Root] CVE-2017-7533 漏洞分析和复现)