Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CODE BLUE 2016.10.20
@st4g3r
Hiroki MATSUKUMA
(@st4g3r)
Newbie Pentester
 Cyber Defense Institute, Inc.
CTF Player
 TokyoWesterns
My interests inc...
tl;dr
Heap Exploitation(x64 Linux/Glibc malloc)
What's "House of Einherjar" ?
 This is a new heap exploitation techniqu...
Overview
Glibc malloc
 Chunk
 Bin
 Consolidating Chunks
House of Einherjar
 Flaw / Flow
 Demo
 Evaluation
 Counte...
"struct malloc_chunk"
 A memory block joins free list after being free()'ed.
 free()'ed block is treated as "struct mal...
TYPE NAME DESCRIPTION
INTERNAL_SIZE_T prev_size Size of previously contigous chunk (shared)
INTERNAL_SIZE_T size Size of i...
"struct malloc_chunk"
 A memory block joins free list after being free()'ed.
 It is ordinarily treated as "struct mallo...
"struct malloc_chunk"
 A memory block joins free list after being free()'ed.
 It is ordinarily treated as "struct mallo...
Glibc malloc Bin
A free chunk belongs to free list(bin).
 Small bins
 MAX_FAST_SIZE < size < MIN_LARGE_SIZE
 MAX_FAST_...
(prev_size)
size
fd
bk
(not used)
bins[n-1]
bins[n]
bins[n+1]
FD
BK
Fig 2. Small bin free list
bins
c
struct malloc_chunk
...
Glibc malloc Consolidating Chunks
It can easily cause fragmentation owing
to frequent allocations and vice versa.
 Let's...
Glibc malloc Consolidating Chunks
Where is the flow of chunk consolidating?
 Let's read glibc!
 free(p)
 __libc_free(p...
(a) Entry point
Fig. 3 _int_free()
(b) Consolidating point
Fig. 3 _int_free()
(c) End point
Fig. 3 _int_free()
Glibc malloc Consolidating Chunks
(prev_size)
size
(a) Test prev_inuse
Fig. 4 Consolidating
size = p->size
If not prev_inu...
Glibc malloc Consolidating Chunks
(prev_size)
size
(b) Relocation
Fig. 4 Consolidating
size = p->size
If not prev_inuse(p)...
Glibc malloc Consolidating Chunks
(prev_size)
size 1
p
(c) New chunk
Fig. 4 Consolidating
p
(prev_size)
size
fd
bk
(not us...
House of Einherjar Flaw / Flow
Our current knowledge
 "p->prev_size" can be shared with previous contiguous
chunk.
 PRE...
House of Einherjar Flaw / Flow
Our current knowledge
 "p->prev_size" can be shared with previous contiguous
chunk.
 PRE...
House of Einherjar Flaw / Flow
(prev_size)
size
data
(prev_size)
size
data
+
pads
1
(a) Before overflowing
Fig. 5 The Hous...
House of Einherjar Flaw / Flow
(prev_size)
size
data
(prev_size)
size
data
+
pads
1
(b) Overflowing
Fig. 5 The House of Ei...
House of Einherjar Flaw / Flow
(prev_size)
size
data
0xdeadbeef
size
data
+
pads
'¥0'
(c) After overflowing
Fig. 5 The Hou...
House of Einherjar Flaw / Flow
(prev_size)
size
data
0xdeadbeef
size
data
+
pads
'¥0'
(c) After overflowing
Fig. 5 The Hou...
House of Einherjar Flaw / Flow
(prev_size)
size
data
0xdeadbeef
size
data
+
pads
'¥0'
(c) After overflowing
Fig. 5 The Hou...
House of Einherjar Flaw / Flow
How to enter into House of Einherjar
 The well-sized chunk will occur OBO Overflow into t...
Demo
http://ux.nu/6Rv6h
House of Einherjar Evaluation
Merit
 It depends on application's memory layout but only
OBO Overflow is required
 Huge ...
House of Einherjar Countermeasures
"struct malloc_chunk" is NOT good
 "chunk->prev_size" SHOULD NOT be overwritable by
n...
Thank You For Your Attention!
Any Questions?
Upcoming SlideShare
Loading in …5
×

[CB16] House of Einherjar — Yet Another Heap Exploitation Technique on GLIBC by Hiroki Matsukuma

1,529 views

Published on

If any susceptible application data to a buffer overflow like a function pointer was on the memory block allocated by the target program, we can assume that Heap-based Buffer Overflow is as amenable to attacks as Stack-based Buffer Overflow. Although the remote attackers have no way to figure out whether it is really exploitable or not because the memory layout is conditional on a target application. Thus, an exploitation to Heap-based Buffer Overflow is not so practical. However it is so interesting and we focus on it.
One objective of attackers is gaining the program counter to lead to an arbitrary code execution and they usually realize that with "write-what-where primitive", an arbitary data write to anywhere, to the susceptible data. An ancient technique called "Unlink Attack" provides direct "write-what-where primitive" but it is not available today thus the recent exploit writers excogitate indirect "write-what-where primitive" by forcing malloc() to return a nearly-arbitrary address. There are several Heap Exploitation techniques like Malloc Maleficarum, a paper with some great techniques published by Phantasmal Phantasmagoria, which provides such indirect "write-what-where primitive". Some of them have been fixed but some others like House of Force and so on have been still available today.
This paper propose the "House of Einherjar", a new technique as an indirect "write-what-where primitive" on the latest GLIBC.

--- Hiroki Matsukuma

Hiroki MATSUKUMA is a web pentest rookie at Cyber Defense Institute, Inc. in Japan, a member of TokyoWesterns.
He was an electrical engineering student at NITTC(National Institute of Technology, Tokyo College). /* However, his interest has been in a computer security before thus he often neglected studying and participated in CTF competitions :P */
Sometimes he gets a good feeling the moment he got a control of an application, when listening EDM and he likes having something good to eat with a girl;)
Now his interest is towards heap implementations, exploitation of embedded systems and suchlike technology related to pwn.

Published in: Technology
  • Be the first to comment

[CB16] House of Einherjar — Yet Another Heap Exploitation Technique on GLIBC by Hiroki Matsukuma

  1. 1. CODE BLUE 2016.10.20 @st4g3r
  2. 2. Hiroki MATSUKUMA (@st4g3r) Newbie Pentester  Cyber Defense Institute, Inc. CTF Player  TokyoWesterns My interests include  Exploitation  Glibc malloc (currently) $whoami
  3. 3. tl;dr Heap Exploitation(x64 Linux/Glibc malloc) What's "House of Einherjar" ?  This is a new heap exploitation technique that forces glibc malloc() to return a nearly-arbitrary address.  User is ordinarily able to read/write to the address returned by malloc().  The concept is abusing consolidating chunks to prevent from the fragmentation.  Off-by-one Overflow on well-sized chunk leads both control of prev_size and PREV_INUSE bit of the next chunk. Proof of Concept  http://ux.nu/6Rv6h
  4. 4. Overview Glibc malloc  Chunk  Bin  Consolidating Chunks House of Einherjar  Flaw / Flow  Demo  Evaluation  Countermeasures
  5. 5. "struct malloc_chunk"  A memory block joins free list after being free()'ed.  free()'ed block is treated as "struct malloc_chunk".  The size of a chunk is aligned on SIZE_SZ*2 bytes. (prev_size) size fd bk (not used) (prev_size) size data + pads SIZE_SZ =8byte User's space (a) in-used (b) free Fig. 1 struct malloc_chunk Shared with previous chunk Glibc malloc Chunk
  6. 6. TYPE NAME DESCRIPTION INTERNAL_SIZE_T prev_size Size of previously contigous chunk (shared) INTERNAL_SIZE_T size Size of itself and its current status struct malloc_chunk *fd Pointer to forwardly linked chunk (free list). struct malloc_chunk *bk Pointer to backwardly linked chunk (free list). Glibc malloc Chunk Table 1: struct malloc_chunk
  7. 7. "struct malloc_chunk"  A memory block joins free list after being free()'ed.  It is ordinarily treated as "struct malloc_chunk".  The size of a chunk is aligned on SIZE_SZ*2 bytes. (prev_size) size fd bk (not used) (prev_size) size data + pads SIZE_SZ =8byte PMA User's space (a) in-used (b) free Fig. 1 struct malloc_chunk Low 3 bits mean chunk status Glibc malloc Chunk Shared with previous chunk
  8. 8. "struct malloc_chunk"  A memory block joins free list after being free()'ed.  It is ordinarily treated as "struct malloc_chunk".  The size of a chunk is aligned on SIZE_SZ*2 bytes. (prev_size) size fd bk (not used) (prev_size) size data + pads SIZE_SZ =8byte PMA User's space (a) in-used (b) free Fig. 1 struct malloc_chunk Low 3 bits mean chunk status  [P]REV_INUSE  IS_[M]MAPPED  NON_MAIN_[A]RENA Glibc malloc Chunk Shared with previous chunk
  9. 9. Glibc malloc Bin A free chunk belongs to free list(bin).  Small bins  MAX_FAST_SIZE < size < MIN_LARGE_SIZE  MAX_FAST_SIZE: 0xa0  MIN_LARGE_SIZE: 0x400  Unsorted bins  The chunk which has just free()'ed temporarily belongs to this list.  There is no size restriction.
  10. 10. (prev_size) size fd bk (not used) bins[n-1] bins[n] bins[n+1] FD BK Fig 2. Small bin free list bins c struct malloc_chunk PMA Glibc malloc Bin
  11. 11. Glibc malloc Consolidating Chunks It can easily cause fragmentation owing to frequent allocations and vice versa.  Let's consider consolidating the chunk being free()'ed and already free()'ed contiguous chunk.  Previous contiguous.  Next contiguous. PREV_INUSE bit  The flag for distinguishing whether the previous contiguous chunk is in used or not.  This is the sole criterion for the consolidating.
  12. 12. Glibc malloc Consolidating Chunks Where is the flow of chunk consolidating?  Let's read glibc!  free(p)  __libc_free(p)  _int_free(av, p, have_lock) <- THIS!
  13. 13. (a) Entry point Fig. 3 _int_free()
  14. 14. (b) Consolidating point Fig. 3 _int_free()
  15. 15. (c) End point Fig. 3 _int_free()
  16. 16. Glibc malloc Consolidating Chunks (prev_size) size (a) Test prev_inuse Fig. 4 Consolidating size = p->size If not prev_inuse(p): prevsize = p->prev_size size += prevsize p += -(long)(prevsize) fd bk (not used) (prev_size) size 0 data + pads p prev p
  17. 17. Glibc malloc Consolidating Chunks (prev_size) size (b) Relocation Fig. 4 Consolidating size = p->size If not prev_inuse(p): prevsize = p->prev_size size += prevsize p += -(long)(prevsize) p p fd bk (not used) (prev_size) size 0 data + pads prev p
  18. 18. Glibc malloc Consolidating Chunks (prev_size) size 1 p (c) New chunk Fig. 4 Consolidating p (prev_size) size fd bk (not used) fd bk (not used) (prev_size) size 0 data + pads p prev p
  19. 19. House of Einherjar Flaw / Flow Our current knowledge  "p->prev_size" can be shared with previous contiguous chunk.  PREV_INUSE bit of "p->size" decides whether the two contiguous chunks will be consolidated or not.  New location of p depends on "p->prev_size".  "p = chunk_at_offset(p, -((long)prevsize))"
  20. 20. House of Einherjar Flaw / Flow Our current knowledge  "p->prev_size" can be shared with previous contiguous chunk.  PREV_INUSE bit of "p->size" decides whether the two contiguous chunks will be consolidated or not.  New location of p depends on "p->prev_size".  "p = chunk_at_offset(p, -((long)prevsize))" Assumptions for House of Einherjar  Three chunks.  p0: the well-sized chunk(includes p1->prev_size).  p1: the small bin sized chunk.  (p2: the chunk to prevent from calling malloc_consolidate()).  p0 will be Off-by-one(OBO) poisoned by NUL byte('¥0').
  21. 21. House of Einherjar Flaw / Flow (prev_size) size data (prev_size) size data + pads 1 (a) Before overflowing Fig. 5 The House of Einherjar shared p0 (used) p1 (used) well-sized
  22. 22. House of Einherjar Flaw / Flow (prev_size) size data (prev_size) size data + pads 1 (b) Overflowing Fig. 5 The House of Einherjar Overflown
  23. 23. House of Einherjar Flaw / Flow (prev_size) size data 0xdeadbeef size data + pads '¥0' (c) After overflowing Fig. 5 The House of Einherjar well-sized p0 (free) p1 (used) shared
  24. 24. House of Einherjar Flaw / Flow (prev_size) size data 0xdeadbeef size data + pads '¥0' (c) After overflowing Fig. 5 The House of Einherjar well-sized p0 (free) p1 (used) sharedsize = p1->size If not prev_inuse(p1): prevsize = p1->prev_size size += prevsize p1 += -(long)(prevsize)
  25. 25. House of Einherjar Flaw / Flow (prev_size) size data 0xdeadbeef size data + pads '¥0' (c) After overflowing Fig. 5 The House of Einherjar well-sized p0 (free) p1 (used) sharedsize = p1->size If not prev_inuse(p1): prevsize = 0xdeadbeef size += prevsize p1 += -(long)(prevsize)
  26. 26. House of Einherjar Flaw / Flow How to enter into House of Einherjar  The well-sized chunk will occur OBO Overflow into the next chunk.  We can put a fake chunk near the target area.  For easy, we should make fd and bk members of fake chunk to point to the fake chunk's self.  We have to be able to calculate the diff between the target area and "p1".  Leaking the two addresses is required.  We have to be able to fix "p1->size" broken by free()'ing.  On the assumption that we can write to the fake chunk anytime.
  27. 27. Demo http://ux.nu/6Rv6h
  28. 28. House of Einherjar Evaluation Merit  It depends on application's memory layout but only OBO Overflow is required  Huge malloc() like "House of Force" is not required. Demerit  The target area will be limited on the location of the fake chunk.  The leaking the two addresses is necessary. Evaluation: "Not so bad"
  29. 29. House of Einherjar Countermeasures "struct malloc_chunk" is NOT good  "chunk->prev_size" SHOULD NOT be overwritable by normal writes to a chunk.  It uses Boundary Tag Algorithm. (It is what it is!) Countermeasures?  Address checking  Is the consolidated chunk address valid?  Stack and heap address spaces are completely different.  It is possible to save a return address.  But that cannot be the solution for House of Einherjar to heap address space.
  30. 30. Thank You For Your Attention! Any Questions?

×