Speaker: Peter Hlavaty
Language: English
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)
CONFidence: http://confidence.org.pl/pl/
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.
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%
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 ?
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!
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 ?