This document discusses various overflow issues that can occur with the splice and vmsplice Linux kernel functions. It describes stack and buffer overflows that can happen due to race conditions when accessing pipe buffers. It also proposes a pool overflow technique using SLUB memory and controlled data read from a TTY device to spray the kernel memory and potentially overflow adjacent objects. Finally, it notes that further research is needed to determine a suitable target and exploit methodology, and hints that pipe buffer sizes may allow overflowing kernel memory allocations.

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!