Attacking DRM subsystem to gain kernel privilege on Chromebooks

My slides for Code Blue 2019

Transcript

1. Attacking DRM subsystem to gain kernel privilege on Chromebooks Di Shen a.k.a. Retme (@returnsme) Keen Lab of Tencent
2. 
    • Di Shen a.k.a. Retme • Sr. Security Researcher of Keen Lab, Tencent • Kernel vulnerability hunting and exploitation since 2014 • @returnsme • github.com/retme7 • Fan of console games, anime and mystery novels()
3. 
    • Chrome OS security: a brief look • Choose a better attack surface: for Chrome PWNium • The Direct Rendering Manager(DRM) • CVE-2019-16508: analysis and exploitation • Demonstration
4.   
      • running the Linux- based Chrome OS • Different brands and models • HP,Dell,ASUS,Lenovo…
5. 
     • Not for video gamers • But still good enough to finish daily work • Easy to use • Some models can be very cheap • It is very SECURE.
6.         
   • Chrome browser • Sandbox • Both apps and system services are isolated and sandboxed. • Secure file system / storage • Read-only root file system • Verified boot and dm-verity • Additional Linux security module is stacked ahead of SELinux • Automatic updates • Fix known bugs ASAP • Apply security patches to the kernel regularly
7. 
    • Use minijail0 to execute system services • Apply different kind of restrictions: • User id • Capabilities • Namespace • Seccomp filter policy • SeLinux policy • More details check the official documents [1] [2]
8. 
     • Firmware, root disk(kernel),system partition can be verified • System partition is verified by dm-verity in kernel. • Details of verified boot [1]
9. 
    • Used by Chrome OS and Android • Implemented in Linux kernel. • Protect system partition from being modified. • Will calculate the checksum of every block on the disk before I/O operation. • Will crash the whole system if the checksum is wrong.
10. 
           • ‘Persistence’ means keep your malicious process persistently alive across reboots • Chrome OS has multiple features to stop persistent attack
11. 
        • dm-verity • noexec mount for writable data partition • Linux security module (LSM) • Have other mitigations for specific persistent exploits in the history
12. ) ( ) • A Linux security module • Reject symlinks that will redirect system’s write actions during boot (designed_docs) • Refuse to mount a path with symlinks • Hardening against loading module/firmware
13. 
     • Chrome OS security: a brief look • Choose a better attack surface: for Chrome PWNium • The Direct Rendering Manager(DRM) • CVE-2019-16508: analysis and exploitation • Demonstration
14. 
        • “We have a standing $150,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page).” – Chrome VRP • Previously it was $100k, raised to $150k this July.
15. ) ( ( • Chrome browser Renderer RCE (in guest mode) • Sandbox escape • OS Persistence
16. ' • CVE-2019-5825: Out-of-bounds write in V8 • CVE-2019-5826: Use-after-free in IndexedDB • CVE-2019-16508: Privilege escalation in kernel mode • CVE-2019-13690: Privilege escalation in user mode • CVE-2019-13689: Chrome OS persistence bug • Credit goes to Gengming Liu, Jianyu Chen, Zhen Feng, Jessica Liu and Retme at Tencent Keenlab
17.    
         
18. 
        CVE-2019-5825 By Jessica on Kcon, Beijing CVE-2019-5826 By Gengming on Blackhat USA, Las Vegas CVE-2019-16508 By Retme on Code Blue, Tokyo CVE-2019-13690 & CVE-2019-13689 By Gengming & Melody on POC, Seoul
19. 
          • The end of March,2019 • We already had V8 bug for RCE and sandbox escape • But no privilege escalation and Persistence • We need ROOT privilege to trigger the persistent exploitation
20.   
       • I didn’t need to find a Linux kernel vulnerability that affect all Linux distribution. • A bug targeted at official Chrome OS hardware will be fine. • Need to make it within 30 days or so • Let’s find a vendor bug on specific Chromebook.
21.  
    
22. • Mediatek, the paradise for bug hunter… • Lenovo S330 • Based on MT8173 platform • Board name ”hana” (-?)
23.    
    Mitigation Enabled
    PXN * Yes PAN Yes UAO No KASLR No Any others No * PXN : Privileged eXecute Never PAN : Privileged Access Never UAO : User Access Override
24.   
    • Bought Lenovo S330 from Amazon UK… • Then wait 2 weeks for the global delivery • Think about which part of code may be vulnerable during my wait • It ‘s Direct Rendering Manager
25. 
     • Chrome OS security: a brief look • Choose a better attack surface: for Chrome pwnium • The Direct Rendering Manager(DRM) • CVE-2019-16508: analysis and exploitation • Demonstration
26. 
          • a subsystem of the Linux kernel • drivers/gpu/drm/ • responsible for interfacing with GPUs • MT8173 is using PowerVR GPU by Imagination
27.      
      • There will be card0,card1,card2… , if you have multiple video card • It is accessible for normal user (chronos) on Chrom OS. • It exposes IOCTL interface for users
28. ) ( ( ) • We have no permission to request the commands which is set these flags: • DRM_ROOT_ONLY • DRM_MASTER • DRM_AUTH • Few commands are OK to request • Not a big attack surface
29. 
                • Will call vendor’s private IOCTL handler if nr > DRM_COMMAND_BASE
30.      
    • /dev/dri/card0 • mkt_ioctls() • /dev/dri/card1 • pvr_drm_ioctls()
31.    
     • Handles PVR_SRVKM_CMD request • Argument • bridge_id [0-24] • bridge_func_id [0-N]
32.    
     • Handles PVR_SRVKM_CMD request • Argument • bridge_id [0-24] • bridge_func_id [0-N]
33.    
     • (bridge_id*bridge_func_id) interfaces can be accessed by user mode • Exactly the attack surface I want!
34. 
           • Recompile the kernel and flash it to Chromebook [1][2] • Define fuzzing rules targeting PowerVR interface PVR_SRVKM_CMD • Run the fuzzer via SSH and wait for one night • Maybe play some games on PS4 during my wait …
35. 
     • Chrome OS security: a brief look • Choose a better attack surface: for Chrome pwnium • The Direct Rendering Manager(DRM) • CVE-2019-16508: analysis and exploitation • Demonstration
36. 
    
     • Stack trace • PVRSRVBridgeSyncPrimOpCreate() • bridge_id = 2; bridge_func_id = 8
37. ) ( ) • Miss checking buffer size coming from user input psSyncPrimOpCreateIN, which may lead to an integer overflow. • It’s able to convert this bug to a heap out-of-bound write, then achieve arbitrary memory overwriting.
38. • ui32BufferSize overflowed • A smaller buffer pArrayArgsBuffer • Heap OOB Write
39.      
    • Compromise pipe subsystem (check my talk on CodeBlue 17) • After OSCopyFromUser() • Write pipe_fd to copy buffer to kaddr (arbitrary kernel address) iov_base iov_len iov_base iov_len … pArrayArgsBuffer 0x2000 bytes 0x2000 bytes pArrayArgsBuffer Kaddr iov_len iov_base iov_len … Overwriting starts from here.
40. 
     • Kernel may crash in 50% by “HARDENED_USERCOPY” • That happens when my heap spray failed, the copy_from_user() overwrite some small heap slots. 128 128 128 128 … pArrayArgsBuffer kmalloc-8192 kmalloc-128 copy_from_user(ptr-object-128,buffer-8192,8192) KERNEL PANIC BY HARDENED_USERCOPY
41. 
       • Seems was back ported to Linux 3.18 by chromium • Boundary check in copy_from/to_user() by instrumentation • check_copy_size()
42.     
    • I copied 8192 bytes to object-128 previously • Actually copying 0x20 bytes is good enough to overwrite iov_base. • The copied content is {0, 0, kADDR, iov_len} 128 128 128 128 … pArrayArgsBuffer kmalloc-8192 kmalloc-128 copy_from_user(ptr-object-128,buffer-8192,0x20) It will NOT crash when my spray failed any more.
43. 
     • Chrome OS security: a brief look • Choose a better attack surface: for Chrome pwnium • The Direct Rendering Manager(DRM) • CVE-2019-16508: analysis and exploitation • Demonstration
44. 
      @returnsme retme7@gmail.com github.com/retme7