Dangers of the Heap

Lecture

Dangers of the Heap

Security vs. Performance

Dangers

More than one way to misuse the heap!

• Forgetting to free memory: leads to resource exhaustion

• Forgetting that we have freed memory: using free memory freeing free memory

• Corrupting metadata used by the allocator to keep track of heap state: conceptually similar to corruption internal function state on the stack

Memory Leaks

Problem: Allocated memory must be explicitly free()d.

Consider the following C code snippet:

int foo()
{
	char *blah = malloc(1024);
	// ...
	// use blah in safe ways
	// ...
	return 1;
}

Q: What happens with the memory pointed to by blah?

A: It is never freed, so this part of the memory is always occupied. If too many such pointers exist, the memory may be exhausted.

Q: Why is this a security issue?

A: Sensitive data might be left in the memory.

Use After Free (UAF)

Consider the following C code snippet:

int main() {
    char *user_input = malloc(8);

    printf("Name? ");
    scanf("%7s", user_input);
    printf("Hello %s!\n", user_input);
    free(user_input);

    long *authenticated = malloc(8);
    *authenticated = 0;

    printf("Password? ");
    scanf("%7s", user_input);

    if (getuid() == 0 || strcmp(user_input, "hunter2") == 0) *authenticated = 1;
    if (*authenticated) sendfile(0, open("/flag", 0), 0, 128);
}

Pointers to an allocation remain valid after free()ing the allocation, and might be used afterwards!

Q: Why is this bad?

A: Modify the code a little bit in order to print out the addresses of user_input and authenticated:

//uaf.c
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include<fcntl.h>
#include <sys/sendfile.h>

int main() {
    char *user_input = malloc(8);
    // Debugging information
    printf("user_input address: %p\n", user_input);

    printf("Name? ");
    scanf("%7s", user_input);
    printf("Hello %s!\n", user_input);
    free(user_input);

    long *authenticated = malloc(8);
    // Debugging information
    printf("authenticated address: %p\n", authenticated);
    *authenticated = 0;

    printf("Password? ");
    scanf("%7s", user_input);

    if (getuid() == 0 || strcmp(user_input, "hunter2") == 0) *authenticated = 1;
    if (*authenticated) sendfile(0, open("./flag", 0), 0, 128);
}

Compile this source code and create a fake flag:

gcc uaf.c -o uaf
echo 'ctf{this_is_a_flag}' > flag

After free(user_input) gets called, the pointer user_input remains valid. Later on, the program allocates another chunk of memory long *authenticated = malloc(8). Since the allocation size (8 bytes) is the same, the memory region owned by user_input now is assigned to authenticated. You can verify this fact based on the debugging information output:

user_input and authenticated have the same address

In the end, UAF is triggered by scanf("%7s", user_input). Since both pointers user_input and authenticated are pointing to the same memory location at this moment, scanf("%7s", user_input) is essentially the same as scanf("%7s", authenticated). If we enter any nonempty password, authenticate will be overwritten, and thus the check if (*authenticated) is bypassed.

Memory Disclosure

Simple case: UAF, but with a printf() instead of a scanf().

Complex case: Some heap implementations (including dlmalloc and ptmalloc) reuse free()d chunks to store metadata.

Some heap implementations (including dlmalloc and ptmalloc) reuse free()d chunks to store metadata. Consider the following C code snippet:

// heap_disclosure.c
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>

int main() {
    char *password = malloc(8);
    char *name = malloc(8);

    printf("Password? ");
    scanf("%7s", password);
    assert(strcmp(password, "hunter2") == 0);
    free(password);

    printf("Name? ");
    scanf("%7s", name);
    printf("Hello %s!\n", name);
    free(name);

    printf("Goodbye, %s!\n", name);
}

Compile it:

gcc heap_disclosure.c -o heap_disclosure

Note that the pointer name shows up in printf after being free()d:

free(name);

printf("Goodbye, %s!\n", name);

This error leaks the address of name from the heap:

heap_disclosure

Metadata Corruption

Allocator metadata can be written, not just read, to cause crazy effects. One of the earliest widespread heap exploits, developed by Solar Designer in 2000:

JPEG COM Marker Processing Vulnerability in Netscape browsers and Microsoft products, and a generic heap-based buffer overflow exploitation technique

The earliest heap exploit, by Solar Designer

Soon formalized in hacker literature in 2001:

• Vudo malloc tricks, by MaXX
• Once upon a free(), by anonymous

Now a whole genre in the hacking scene!

Hackers are Weird: The Rise of the Houses

Phantasmal Phantasmagoria developed a "lore" around heap metadata corruption:

Bugtraq: The Malloc Maleficarum

The Malloc Maleficarum

Described and named a number of metadata corruption techniques:

• House of Prime

• House of Mind

• House of Force

• House of Lore

• House of Spirit (still works nowadays)

• House of Chaos

Things got out of hand quick. Later work:

• House of Underground

• House of Orange

• House of Einherjar

• House of Rabbit

• House of Botcake

Learn more:

GitHub - shellphish/how2heap: A repository for learning various heap exploitation techniques.GitHub

how2heap

The Danger of Overlapping Allocations

Typically, heap metadata corruption is used to confuse the allocator into allocating overlapping memory. As we saw with UAF, this can be extremely dangerous.

If two pointers are pointing to the same memory, and one of the pointers is treated by the program in a security-critical manner, and the other one can be written to or read by an attacker, it's game over!

"Security-critical manner?"

• authentication variables

• Function pointers (control flow hijack)

• Program metadata such as length (inducing memory errors)

• Sensitive data (such as the flag)