CSC 495/583 Topics of Software Security Heap Exploitation (2) Class11 CSC 495/583 Topics of Software Security Heap Exploitation (2) Dr. Si Chen (schen@wcupa.edu)

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

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; }

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

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

Pseudo Memory Map Runtime Memory Runtime Memory MBE - 04/07/2015 6 0x00000000 – Start of memory 0x00000000 – 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 0x08048000 – Start of .text Segment 0x08048000 – Start of .text Segment 0xb7ff0000 – Top of heap 0xbfff0000 – Top of stack 0xFFFFFFFF – End of memory MBE - 04/07/2015 Heap Exploitation 6

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

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

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

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

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)

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

Heap Overflows Buffer overflows are basically the same on the heap as they are on the stack 0x00000000 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

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!

heap0.c

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

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

Shellcode and Attack

Function Pointers on the Heap

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

Heap-Based Control Hijacking ShellCode

Heap Spraying

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

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

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. 

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.

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.

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.

First-fit behavior The state of unsorted bin progresses as: 'a' freed. ‘malloc’ request. heada(300 byte)tail heada2(300-250-8byte)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).

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

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

UAF

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 email or drive-by download.

Double Free Double Free

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

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

Forging chunks Forging chunks

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.

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 ]

Unlink Exploit Unlink Exploit

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. 

Before freed chunk 2

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.

After freed chunk 2

Shrinking Free Chunks Shrinking Free Chunks

Shrinking Free Chunks

Q & A

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

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

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

Use After Free (UAF) free()’d free()’d Runtime Memory Heap Segment 0x00000000 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

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

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

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

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

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

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]; };

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

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

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

Heap Spray in Action Runtime Memory filler = “AAAAAAAAAAAAA...”; 0x00000000 – Start of memory 0x08048000 – .text Segment in ELF 0x09104000 – Top of heap filler = “AAAAAAAAAAAAA...”; for(i = 0; i < 3000; i++) { temp = malloc(1000000); memcpy(temp, filler, 1000000); } 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

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;

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

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 ~18446744 terabytes) Targeted sprays are still useful in scenarios that you have a partial heap ptr overwrite or need to do some heap grooming

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