Slide 1

Slide 1 text

SPLICE™ When is something overflowing

Slide 2

Slide 2 text

 Log  PoC  Bug  More problems Stack overflow  Buffer overflow  Overflowing too much  No data problem  Memory pools and SLUB  introduction 一步一步

Slide 3

Slide 3 text

#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.

Slide 4

Slide 4 text

PoC https://lkml.org/lkml/2012/6/7/156 RACE:  fcntl => pipe_set_size  vmsplice / splice => do_splice

Slide 5

Slide 5 text

 Multiple access to pipe->buffers  No locks present  Fast alloc => from stack  Big alloc => from heap  Race to confuse its origin! BUG - RACE

Slide 6

Slide 6 text

not one function issue only!

Slide 7

Slide 7 text

default_file_splice_read @race, @controlled content, @stack overflow, @buffer overflow

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Stack overflow options 1. No canaries! 2. Attack LR => PC 3. Target params! 4. Target locals 5. … 6. Fail on splice shrink 

Slide 10

Slide 10 text

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%

Slide 11

Slide 11 text

WHAT NEXT ?

Slide 12

Slide 12 text

BUFFER OVERFLOW @kernel pool, @SLUB, @pipe_set_size, @kmalloc

Slide 13

Slide 13 text

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!

Slide 14

Slide 14 text

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!!

Slide 15

Slide 15 text

BUT ! DATA CONTENT PROBLEM ! Wtf, we exit too soon due to error on data read, no controlled data anymore ?

Slide 16

Slide 16 text

NEW POOL SPRAY ? default_file_splice_read .. AGAIN ..

Slide 17

Slide 17 text

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!

Slide 18

Slide 18 text

NEW POOL SPRAY! NO MEMORY PRESSURE! CONTROLLED DATA!

Slide 19

Slide 19 text

SPRAY Implementation Why design matter #1

Slide 20

Slide 20 text

VULN IMPLEMENTATION Why design matter #2

Slide 21

Slide 21 text

Overflows vs Kernel Pool SLUB Randomization but chosen mainly from last SLAB SLAB organized by size similar sized objects covered by same SLAB

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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 ?

Slide 26

Slide 26 text

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 ?

Slide 27

Slide 27 text

btw. Software Security! .. tale about calculator : how some guys protect others ..

Slide 28

Slide 28 text

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!

Slide 29

Slide 29 text

Aftermath Low hanging fruits Poping calcs Good luck …

Slide 30

Slide 30 text

https://twitter.com/JohnLaTwC/status/601101229939294208/photo/1

Slide 31

Slide 31 text

.. shameless plug .. #whoarewe

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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 ]

Slide 35

Slide 35 text

KEEN TEAM - KNOWLEDGE * multiple presentations on chinese domestic conferences & lectures at universities not listed here ten months highlights

Slide 36

Slide 36 text

10.24.2015 Pick a device, name your own challenge!

Slide 37

Slide 37 text

Thank You! Q & A @K33nTeam hr (at) keencloudtech.com We are hiring! :) Interns wanted!