When is something overflowing

This talk will cover how powerfull are buffer overflows, how weak are mitigations against them, why are buffer overflows still possible in those days, how generic are they, and example how useful is turn race conditions to buffer overflow. Race conditions are nice example for that, because they are one of the hardest to find and on of the easiest to make. example is on Linux kernel (droids included), but talk will be keeped for buffer overflows in general (mainly for windows & Linux kernel)

Transcript

1. SPLICE™ When is something overflowing
2.  Log  PoC  Bug  More problems Stack overflow  Buffer overflow  Overflowing too much  No data problem  Memory pools and SLUB  introduction 一步一步
3. #trinity #race condition #2012 #< 3.4.67 #most of droids 2014 https://lkml.org/lkml/2012/6/6/713 Date => Wed, 6 Jun 2012 22:51:17 - 0400 From => Dave Jones <> Subject => vmsplice triggering bug in kfree.
4. PoC https://lkml.org/lkml/2012/6/7/156 RACE:  fcntl => pipe_set_size  vmsplice / splice => do_splice
5.  Multiple access to pipe->buffers  No locks present  Fast alloc => from stack  Big alloc => from heap  Race to confuse its origin! BUG - RACE
6. not one function issue only!
7. default_file_splice_read @race, @controlled content, @stack overflow, @buffer overflow
9. Stack overflow options 1. No canaries! 2. Attack LR => PC 3. Target params! 4. Target locals 5. … 6. Fail on splice shrink 
10. Stack attack revival !! 1. Lets pipe->buffers be small == stack alloc 2. Race pie->buffers before kmalloc to vec => aka vec = kmalloc 3. Race again, before splice shrink! 4. Pwn stack by spd.pages! 5. … 6. Need to handle with stack layout per ROM, sometimes not possible – aka bad layout 7. FAIL most of time, 2 races in short time! 99.9999999%
11. WHAT NEXT ?
12. BUFFER OVERFLOW @kernel pool, @SLUB, @pipe_set_size, @kmalloc
13. Lets do pool overflow! (SLUB) Tactic 1. pipe->buffers > PIPE_DEF_BUFFERS means no panic if kfree! 2. race pipe->buffers to be bigger than passed to kmalloc means overflow 3. read our controlled content (kernel_readv) 4. pwn some adjacent data to kmalloced buffer ptr is kernel one, but data are controlled problems 1. we overflow with IOVEC structure!! { KERNEL PTR, 0x1000 } No so cool controlled, but still controlled enough! 2. we do kmalloc followed by overflow means, targeted buffer should be positioned already! kmalloc should return memory right before targeted buffer 3. we do kmalloc not only for VEC buffer! Multiple overflows! Multiple chances to panic!
14. DEFAULT FILE SPLICE READ struct iovec *vec; struct splice_pipe_desc { struct page **pages; struct partial_page *partial; … } POSSIBLE TO EXIT SOONER! ”/dev/null” GOOD : Reduce overflowing buffers - vec  struct iovec (size == 8) - spd.pages  struct page (size == 4) BAD : different SLAB => not following buffers, overflow something different => kfree_skb problem!!
15. BUT ! DATA CONTENT PROBLEM ! Wtf, we exit too soon due to error on data read, no controlled data anymore ?
16. NEW POOL SPRAY ? default_file_splice_read .. AGAIN ..
17. POOL SPRAY NOT SO EASY 1. You have to ship data to pipe 2. With splice 3. Splice have to use default_file_splice_read 4. /dev/ptmx a.k.a TTY  5. You can to load data to TTY 6. Splice to pipe 7. Read from pipe 1. We have just limited number of TTY == 0x1fd to be exact 2. Not enough for pool spray, but not necessary anyway  repeat!! 3. avoiding memory pressure as side effect!
18. NEW POOL SPRAY! NO MEMORY PRESSURE! CONTROLLED DATA!
19. SPRAY Implementation Why design matter #1
20. VULN IMPLEMENTATION Why design matter #2
21. Overflows vs Kernel Pool SLUB Randomization but chosen mainly from last SLAB SLAB organized by size similar sized objects covered by same SLAB
22. Probe and pwn! 1. choose two semi-controlled objects 2. Target and Victim 3. Should cover same SLAB 4. Full many SLABs by target 5. Free one target per SLAB 6. Try to fill holes by victim 7. Trigger over/under flow from victim to hit target 8. pwn
23. memory object separation • Linux kernel – caches • many times object specific cache • But cache can be fully filled as well • Then need to allocate new one • Reallocation cache can be played with! • Not so easy as with normal objects, but doable .. • Windows kernel – sessions • Many powerful objects in same session • Choose one of them & pwn
24. POWER lies in DESIGN Full control about kmalloc & kfree Control (at least semi!) about the object content Objects contains plain *pointers* and members No integrity checks on member state No effective sentinels (page_noaccess) between objects / memory chunks even on 64bit! Limited Randomization - everytime same chunk base http://www.slideshare.net/ PeterHlavaty/back-to-the-core
25. SPLICE not done yet … Whats COVERED BY PRESO  Race no problem  Reduced overflow to 2 buffers (vec, pages)  Spray to fill data to controlled state  Play with SLUB TODO OWN-RESEARCH  WHAT is our TARGET ?  EXEC ?  PXN ?  PAN & arm64 ?
26. Hint : kmalloc and pipe_set_size  We set sizes for kmalloc trough pipe_set_size  pipe_set_size (->buffers) is limited to some sizes  1, 2, 4, 8, 0x10, 0x20, 0x40, 0x80, 0x100  That’s all!  We are not interested in content of pipe, just about pipe->buffers, because …  kmalloc take those sizes and multiply by siozeof(iovec) !  On kmalloc goes only sizes :  0x20, 0x40, 0x80, 0x100  Results in following kmallocs : 0x80, 0x100, 0x200, 0x400  Here is necessary some techs!  For TTY was used tty_buffer, size in 0x400 SLAB, cool!  But magic there, and we scatter it because of pattern { KERNEL PTR, 0x1000 }  Some other candidates ?
27. btw. Software Security! .. tale about calculator : how some guys protect others ..
28. Attack chain • Social engineering • Vulnerability Attack vector • Killing 0days proactive solution! Prevent to automatic install malware • Cure after- effects Dissecting malware If proactive fails Targeted attack here won already!
29. Aftermath Low hanging fruits Poping calcs Good luck …
30. https://twitter.com/JohnLaTwC/status/601101229939294208/photo/1
31. .. shameless plug .. #whoarewe
32. KEEN TEAM - TIMELINE 2010前 2010.7 2010- 2012 Pwn2Own 2013 Pwn2own 2014 Emergency experts Global Platinum prize XP Guard Security Alliance GeekPwn 2014 Evaluation CNMSRC founding team 2013.11 2014.2 2014.3 2014.10 Project Zero 2014.12 Tesla recognition 2014.11 Pwn2Own 2015 2015.3 2015.4 CodeGate CTF – 0ops
33. KEEN TEAM - GEEKS http://forum.xda-developers.com/galaxy-s6/general/ root-pingpongroot-s6-root-tool-t3103016/post60600131 PINGP0NG ROOT wushi (@team509) memeda (@antlr7) idl3r (xda : idler1984) Qoobee (@EvilLeoC) @K33nTeam
34. KEEN TEAM - TECHNIQUES Isolated heap bypass [ blog – MS14-056 ] CC-shellcoding framework [ nosuchcon ] Webkit exploitation [ cansecwest ] VadRoot (vm_area) + PageTable pwn [ syscan ] Pool spray tech [ confidence ] 1bit flip - kernel escape (kernel code exec) [ recon ]
35. KEEN TEAM - KNOWLEDGE * multiple presentations on chinese domestic conferences & lectures at universities not listed here ten months highlights
36. 10.24.2015 Pick a device, name your own challenge!
37. Thank You! Q & A @K33nTeam hr (at) keencloudtech.com We are hiring! :) Interns wanted!