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.

1. CODE BLUE 2016.10.20
@st4g3r

2. Hiroki MATSUKUMA
(@st4g3r)
Newbie Pentester
 Cyber Defense Institute, Inc.
CTF Player
 TokyoWesterns
My interests include
 Exploitation
 Glibc malloc (currently)
$whoami

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. Overview
Glibc malloc
 Chunk
 Bin
 Consolidating Chunks
House of Einherjar
 Flaw / Flow
 Demo
 Evaluation
 Countermeasures

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. 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. "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. "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. 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. (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. 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. 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. (a) Entry point
Fig. 3 _int_free()

14. (b) Consolidating point
Fig. 3 _int_free()

15. (c) End point
Fig. 3 _int_free()

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Demo
http://ux.nu/6Rv6h

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. 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. Thank You For Your Attention!
Any Questions?