From Profiling to Kernel Exploiting

Editor's Notes

1. Performance counters for Linux are a new kernel-based subsystem that provide a framework for performance analysis. They cover both hardware features and software features
2. Syscall perf_event_open is enabled on most of the latest smart phones. There is no strong relationship between the Android version and the Android customized Linux version. Vendors can also customize their linux kernel and SElinux policy. Most Android 4.4.4 to 6.0.1 have enabled this syscall. An application which has no permission required can invoke this syscall. Many CPU vendors would like to add their PMU to Linux for specific performance testing. These codes will not be merged into the mainline of Linux. So these codes may not be totally reviewed.
3. Here is the code relationship of perf. Perf Subsystem has many architecture and vendor related codes, many of the codes are added by vendor, not in mainline of Linux. The red square marked the position where the bugs mostly exist.
4. Here are 4 ways for me to detect bugs in perf. Thanks to these two guys , they released a paper and a perf_fuzzer tool. That helps me a lot. Trinity is a wellkown system call fuzzer.It sometimes help me. Than you should read the codes by yourself and write tools to test specific codes.
5. I have found five bugs in the perf subsystem of Android. Google has published three of them. CVE-2016-0805 and CVE-2016-0843 are out of boundary access bugs in kernel. Here the unpublished critical bug can root nexus 6P
6. I will exploit the critical bug CVE-2016-0819 to get root on Nexus 6. This bug exists in all Android Smart Phones which have Qualcomm CPU and Linux version 3.10 series.
7. Here is the bug related source code. The red lines are added by Qualcomm or Google. Variable constraint_duplicate is added into function perf_release. Once we invoke close() and set variable constraint_duplicate to 1, the event state will be changed from OFF to ACTIVE again.
8. If we set constraint_duplicate in user space , a double delete on a node will occur.
9. Here is a test case code. We can use perf_event_open , ioctl and close to trigger this bug - it will then crash the whole system.
10. But we should remember four key things. Delete does not = free 1,2,3,4
11. This shows the hlist . Every node has a next pointer which points to the next node, they also have a pprev pointer which points to the previous node. The hlist starts from a list head.
12. Here is the node delete function of hlist. Deleting one node, the pprev point of the node will be set to list poison2. List poison 2 = 200200 We can then use memory map to put memory space to that address. I use the parameter MAP_POPULATE and mlock to make sure the physical memory is mapped to the virtual address 0x200200 . In March’s Security Bulletin, Google set the LIST_POISON2 to 0x00000200. When the value is smaller than mmap_min_addr it mitigates the problem.
13. Here I will demo the double delete operation   I assume there are four nodes - node10 to node 40. They are connected with each other.   First I will control node 20   Now node 10 will connect to node 30 and node 30 pprev point will connect to node 10.   Node 20’s pprev point will connect directly to 200200   Next I close node 20. The program will treat the memory in address 200200 as a node. The node 200200 next point will point to node 30.   Now we leak Node 30’s address to user space. Node 20 is now freed.   Then I close node 30 and node 30 is freed   Now Node 10 next point points to a free space. Use After Free
14. We must create a “grace period” to run hlist_del_rcu. An easy way to do this is calling sleep (). The grace period is a term of RCU.. RCU means read, copy, update. RCU will delay the delete operation But if we invoke sleep () the process will schedule out the CPU. All nodes will be deleted from the list. After sleep () is returned all nodes will need to be added back into the list again. That will create an infinite loop in the list. This is the side effect of invoking sleep(). So how do we refill the freed node?
15. I try to create this memory layout in kernel. Every 4 perf_event objects are located on one page. But the fd number may not equal the image described. The real situation is more complicated. One process can have only 1024 fds. So fork out more child process makes it easier to create the memory layout
16. Thanks to these three guys – they supplied the technology that enabled me to spray random data to kernel space and still know where it is.
17. According to kernel memory reuse rule, I exploited the UAF bug: 1. By continuously exposing the next node address until I found a node, at the start of a page. 2. I then freed one more page to increase the spray success rate. 3. Using ret2dir technology I sprayed data to the node at the beginning of the page. 4. I commanded the kernel to traverse the list and used a function pointer that I controlled.
18. The root work is very like GeekBen's TowelRoot Source Code: I set the address limit of the thread to the max number of integers This enabled me to read and write the whole kernal space. Next I set the SElinux enforcing variable to 0 to bypass the SELinux Modifying the credentials and the SELinux security object – we now have the root.
19. Now I show my exploit here. At the moment it is unstable. It may fail or crash the system. Using adb shell is more successful If I fail I will try again. Now it forks more child processes , every child process has 1000 fds. It increases the memory space to low virtual address. I found a node at page start, and I try to spray data to this address. Opps it failed
20. Thank you everyone for your attention. Today I have introduced to you, a new Android bug pool to help protect our customers security better. I am happy now to answer any questions you may have.