1. CSC 495/583 Topics of Software Security Heap Exploitation (2)
Class11
CSC 495/583 Topics of Software Security Heap Exploitation (2)
Dr. Si Chen

2. It’s just another segment in runtime memory
The Heap 0x
Runtime Memory
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
It’s just another segment in runtime memory
0xFFFFFFFF

3. Basics of Dynamic Memory
int main() {
char * buffer = NULL;
/* allocate a 0x100 byte buffer */ buffer = malloc(0x100);
/* read input and print it */ fgets(stdin, buffer, 0x100); printf(“Hello %s!\n”, buffer);
/* destroy our dynamically allocated buffer */ free(buffer);
return 0; }

4. Heap vs Stack Heap Dynamic memory allocations at runtime
Objects, big buffers, structs, persistence, larger things
Slower, Manual
Done by the programmer
malloc/calloc/recalloc/free
new/delete
Stack
Fixed memory allocations known at compile time
Local variables, return addresses, function args
Fast, Automatic
Done by the compiler
Abstracts away any concept of allocating/de-allocating

5. unsigned int * buffer = NULL; buffer = malloc(0x100);
Heap Chunks
unsigned int * buffer = NULL; buffer = malloc(0x100);
//Out comes a heap chunk
Heap Chunk
Previous Chunk Size (4 bytes)
Chunk Size (4 bytes)
Data
(8 + (n / 8)*8 bytes)
Flags
*(buffer-2)
*(buffer-1)
*buffer

6. Pseudo Memory Map Runtime Memory Runtime Memory MBE - 04/07/2015 6
0x – Start of memory
0x – Start of memory
Runtime Memory
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Runtime Memory
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
0x – Start of .text Segment
0x – Start of .text Segment
0xb7ff0000 – Top of heap
0xbfff0000 – Top of stack
0xFFFFFFFF – End of memory
MBE - 04/07/2015
Heap Exploitation 6

7. Heap Allocations Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
0xFFFFFFFF

8. Heap Allocations Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
0xFFFFFFFF

9. Heap Allocations Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
0xFFFFFFFF

10. Heap chunks exist in two states
Heap Chunks – In Use
Heap chunks exist in two states
in use (malloc’d)
free’d
Heap Chunk
Previous Chunk Size (4 bytes)
Chunk Size (4 bytes)
Data
(8 + (n / 8)*8 bytes)
Flags
*(buffer-2)
*(buffer-1)
*buffer

11. free(buffer); Heap Chunk (freed) Forward Pointer Backwards Pointer
Heap Chunks – Freed
free(buffer);
Forward Pointer
A pointer to the next freed chunk
Backwards Pointer
A pointer to the previous freed chunk
Heap Chunk (freed)
Previous Chunk Size (4 bytes)
Chunk Size (4 bytes) FD
(4 bytes) BK
(4 bytes)
Flags
*(buffer-2)
*(buffer-1)
*buffer
*(buffer+1)

12. Heap Overflows Runtime Memory Heap Segment 0x00000000 Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
0xFFFFFFFF

13. Heap Overflows
Buffer overflows are basically the same on the heap as they are on the stack 0x
Runtime Memory
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA …
heap overflow
Data
Previous Chunk Size
Chunk Size
Data
0xFFFFFFFF

14. Heap Overflows
In the real world, lots of cool and complex things like objects/structs end up on the heap
Anything that handles the data you just corrupted is now viable attack surface in the application
It’s common to put function pointers in structs which generally are malloc’d on the heap
Overwrite a function pointer on the heap, and force a codepath to call that object’s function!

15. heap0.c

16. First object on heap; name[64]
Second object on heap; fp  contains a pointer
Winner() – We want to execute this function

17. Second object on heap; fp  contains a pointer
Winner() – We want to execute this function
malloc() allocates storage on the heap
fp points to nowinner()
argv[1] copied into 64-byte arry on the heap,
without checking its length... oops

22. Shellcode and Attack

23. Function Pointers on the Heap

24. Function Pointers on the Heap
Suppose vtable is on the heap next to a string object:

25. Heap-Based Control Hijacking
ShellCode

26. Heap Spraying

27. Doug Lea’s Memory Allocator
The GNU C library and most versions of Linux are based on Doug Lea’s malloc (dlmalloc) as the default native version of malloc

28. Free Chunks in dlmalloc
Organized into circular double-linked lists (bins)
Each chunk on a free list contains forward and back pointers to the next and previous free chunks in the list
Chunk size is stored in the last four bytes of the free chunk

30. Bins
A bin is a list (doubly or singly linked list) of free (non-allocated) chunks. Bins are differentiated based on the size of chunks they contain:
Fast bin
There are 10 fast bins.
Each of these bins maintains a single linked list.
Addition and deletion happen from the front of this list (LIFO manner).
Unsorted bin
There is only 1 unsorted bin.
Small and large chunks, when freed, end up in this bin. 

31. Bins
A bin is a list (doubly or singly linked list) of free (non-allocated) chunks. Bins are differentiated based on the size of chunks they contain:
Small bin
There are 62 small bins. Small bins are faster than large bins but slower than fast bins.
Each bin maintains a doubly-linked list. Insertions happen at the 'HEAD' while removals happen at the 'TAIL' (in a FIFO manner).
Large bin
There are 63 large bins.
Each bin maintains a doubly-linked list.
A particular large bin has chunks of different sizes, sorted in decreasing order (i.e. largest chunk at the 'HEAD' and smallest chunk at the 'TAIL').
Insertions and removals happen at any position within the list.

32. Unlink #define unlink(P, BK, FD) { FD = P->fd; BK = P->bk;
FD->bk = BK;
BK->fd = FD; }
This is a defined macro which removes a chunk from a bin.
Check if chunk size is equal to the previous size set in the next chunk. Else, an error ("corrupted size vs. prev_size") is thrown.
Check if P->fd->bk == P and P->bk->fd == P. Else, an error ("corrupted double-linked list") is thrown.
Adjust forward and backward pointers of neighboring chunks (in list) to facilitate removal:
Set P->fd->bk = P->bk.
Set P->bk->fd = P->fd.

33. First-fit behavior
This technique describes the 'first-fit' behavior of glibc's allocator. Whenever any chunk (not a fast chunk) is freed, it ends up in the unsorted bin.
Insertion happens at the HEAD of the list.
On requesting new chunks (again, non fast chunks), initially unsorted bins will be looked up as small bins will be empty.

34. First-fit behavior The state of unsorted bin progresses as:
'a' freed.
‘malloc’ request.
heada(300 byte)tail
heada2( byte)tail
‘a1’ is returned
'a' chunk is split into two chunks 'a1' and 'a2' as the requested size (250 bytes) is smaller than the size of the chunk 'a' (300 bytes).

35. First-fit behavior
This is also true in the case of fast chunks. Instead of 'freeing' into unsorted bin, fast chunks end up in fastbins.
The state of unsorted bin progresses as:
'a' freed.
’b' freed.
’c' freed.
’d' freed.
‘malloc’ request.
headatail
headbatail
headcbatail
headdcbatail
headcbatail
headbatail
headatail
headtail

36. Use After Free Use After Free (UAF)
A class of vulnerability where data on the heap is freed, but a leftover reference or ‘dangling pointer’ is used by the code as if the data were still valid
Most popular in Web Browsers, complex programs
Also known as UAF

37. UAF

38. Use-After-Free in the Real World
The attacks are targeting IE 8 and 9 and there’s no patch for the vulnerability right now…
The vulnerability exists in the way that Internet Explorer accesses an object in memory that has been deleted or has not been properly allocated. The vulnerability may corrupt memory in a way that could allow an attacker to execute arbitrary code…
The exploit was attacking a Use After Free vulnerability in IE’s HTML rendering engine (mshtml.dll) and was implemented entirely in Javascript (no dependencies on Java, Flash etc), but did depend on a Microsoft Office DLL which was not compiled with ASLR (Address Space Layout Randomization) enabled.
The purpose of this DLL in the context of this exploit is to bypass ASLR by providing executable code at known addresses in memory, so that a hardcoded ROP (Return Oriented Programming) chain can be used to mark the pages containing shellcode (in the form of Javascript strings) as executable… The most likely attack scenarios for this vulnerability are the typical link in an or drive-by download.

39. Double Free
Double Free

40. Double Free
Freeing the same chunk of memory twice, without it being reallocated in between
Can lead to memory leaks.
Start with a simple case:
The chunk to be freed is isolated in memory
The bin (double-linked list) into which the chunk will be placed is empty

41. Double Free Both ‘d’ and ‘f’ pointers point to the same memory address
The state of unsorted bin progresses as:
'a' freed.
’b' freed.
‘a’ freed again.
‘malloc’ request for d.
‘malloc’ request for e.
‘malloc’ request for f.
Both ‘d’ and ‘f’ pointers point to the same memory address
Any changes in one will affect the other
headatail
headbatail
headabatail
headbatail
’a’ is returned
headatail
’b’ is returned
headtail
’a’ is returned

42. Forging chunks
Forging chunks

43. Forging chunks After a chunk is freed, it is inserted in a binlist.
However, the pointer is still available in the program.
If the attacker has control of this pointer, he/she can modify the linked list structure in bins and insert his/her own 'forged' chunk.

44. headatail The state of unsorted bin progresses as: 'a' freed.
a's fd pointer changed to point to 'forged chunk'.
'malloc' request
headatail
headaforged chunk undefined
headforged chunk undefined
headundefined
[ forged chunk is returned to the victim ]

45. Unlink Exploit
Unlink Exploit

46. A new fake chunk is created in the 'data' part of chunk1.
First, we malloc two chunks chunk1and chunk2 with size 0x80 to ensure that they fall in the smallbin range. 
 Next, we assume that the attacker somehow has unbounded control over the contents of chunk1
A new fake chunk is created in the 'data' part of chunk1. 

47. Before freed chunk 2

48. A new fake chunk is created in the 'data' part of chunk1.
First, we malloc two chunks chunk1and chunk2 with size 0x80 to ensure that they fall in the smallbin range. 
 Next, we assume that the attacker somehow has unbounded control over the contents of chunk1
A new fake chunk is created in the 'data' part of chunk1. 
As soon as chunk2 is freed, it is handled as a small bin. Recall that previous and next chunks (by memory) are checked whether they are ‘free’ or not. If any chunk is detected as ‘free’, it is unlinked for the purpose of merging consecutive free chunks.

49. After freed chunk 2

50. Shrinking Free Chunks
Shrinking Free Chunks

51. Shrinking Free Chunks

53. Q & A

54. Use After Free Use After Free (UAF)
A class of vulnerability where data on the heap is freed, but a leftover reference or ‘dangling pointer’ is used by the code as if the data were still valid
Most popular in Web Browsers, complex programs
Also known as UAF

55. Use After Free (UAF) Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
pointer
0xFFFFFFFF

56. Use After Free (UAF) free()’d Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
pointer
free()’d
0xFFFFFFFF

57. Use After Free (UAF) free()’d free()’d Runtime Memory Heap Segment0x
Runtime Memory
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
free()’d
???
free()’d
0xFFFFFFFF

58. Use After Free (UAF) Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
pointer
dangling
0xFFFFFFFF

59. Use After Free (UAF)
Dangling Pointer
A left over pointer in your code that references free’d data and is prone to be re-used
As the memory it’s pointing at was freed, there’s no guarantees on what data is there now
Also known as stale pointer, wild pointer

60. Use After Free (UAF) Runtime Memory Heap Segment 0x00000000
Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
pointer
dangling
0xFFFFFFFF

61. Use After Free (UAF) Runtime Memory Heap Segment Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
Previous Chunk Size
malloc()
Chunk Size
pointer
Newly allocated data
0xFFFFFFFF
dangling

62. Use After Free (UAF) Runtime Memory Heap Segment Libraries (libc)
ELF Executable
.text segment
.data segment
Heap
Stack
Heap Segment
>
Grows towards higher memory
Previous Chunk Size
Chunk Size
Data
Previous Chunk Size
malloc() fgets()
...
Chunk Size
AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAA
pointer
dangling

63. Use After Free (UAF)
To exploit a UAF, you usually have to allocate a different type of object over the one you just freed
struct toystr {
void (* message)(char *); char buffer[20]; };
struct person {
int favorite_num; int age;
char name[16]; };

64. Use After Free
You actually don’t need any form of memory corruption to leverage a use after free
It’s simply an implementation issue
– pointer mismanagement

65. Heap Spraying Heap Spraying
A technique used to increase exploit reliability, by filling the heap with large chunks of data relevant to the exploit you’re trying to land
It can assist with bypassing ASLR
A heap spray is not a vulnerability or security flaw

66. Heap Spray in Action Runtime Memory filler = “AAAAAAAAAAAAA...”;
0x – Start of memory
0x – .text Segment in ELF 0x – Top of heap
filler = “AAAAAAAAAAAAA...”;
for(i = 0; i < 3000; i++) {
temp = malloc( ); memcpy(temp, filler, ); }
Runtime Memory
Libraries (libc)
ELF Executable
Heap
Stack
0xbfff0000 – Top of stack
0xFFFFFFFF – End of memory

67. Heap Spray in Action Runtime Memory filler = “AAAAAAAAAAAAA...”;
0x – Start of memory
0x – .text Segment in ELF 0x – Top of heap
filler = “AAAAAAAAAAAAA...”;
for(i = 0; i < 3000; i++) {
temp = malloc( ); memcpy(temp, filler, ); }
0xbbe09e00 – bottom of heap
0xbfff0000 – Top of stack
0xFFFFFFFF – End of memory
Runtime Memory
Libraries (libc)
ELF Executable
Heap AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA
Stack
3GB of AAAAAAAAA’s

68. Heap Spraying in the Wild
Generally found in browser exploits, rare in CTF and wargames but still something you should be aware of
Usually heap sprays are done in something like javascript placed on a malicious html page
memory = new Array(); for(i = 0; i < 0x100; i++)
memory[i] = ROPNOP + ROP;

69. On 32bit systems your address space is at maximum 4GB (232 bytes)
Heap Spraying on 32bit
On 32bit systems your address space is at maximum 4GB (232 bytes)
Spray 3GB of A’s onto the heap?
– Note: It’s unlikely you would ever need to spray 3GB of anything as heap locations can be somewhat predictable, even with ASLR

70. On 64bit heap spraying can’t really be used to bypass ASLR
Heap Spraying on 64bit
On 64bit heap spraying can’t really be used to bypass ASLR
– Good luck spraying anywhere near 264 bytes (spoiler: that’s ~ terabytes)
Targeted sprays are still useful in scenarios that you have a partial heap ptr overwrite or need to do some heap grooming

71. Heap Spray Payloads
Pretty common to spray some critical value for your exploit, fake objects, or ROP chains