What is Use-After-Free Vulnerability? Ways to Exploit, Examples and Impact

Nandini

— 6 min read
What is Use-After-Free Vulnerability? Ways to Exploit, Examples and Impact

Memory corruption vulnerabilities have long been the holy grail for security researchers and attackers alike. Among these, the Use-After-Free (UAF) vulnerability stands out as one of the most prevalent and dangerous classes of bugs found in modern software written in low-level languages like C and C++. In this guide, we will dive deep into the mechanics of memory management, explore how UAF vulnerabilities arise, and look at the technical methods used to exploit them in the real world.

Understanding Memory Management: The Heap vs. The Stack

To understand a Use-After-Free vulnerability, we first need to understand how applications manage memory. Most programs use two primary areas of memory: the Stack and the Heap.

The Stack is used for static memory allocation. It follows a Last-In-First-Out (LIFO) structure and is managed automatically by the CPU. When a function is called, its local variables are pushed onto the stack; when the function exits, they are popped off. This is highly efficient but lacks flexibility.

The Heap, on the other hand, is used for dynamic memory allocation. This is where developers allocate memory at runtime when they don't know the exact size of the data beforehand. In C, this is done using functions like malloc(), calloc(), or realloc(). Unlike the stack, the heap is not managed automatically. The developer is responsible for tracking that memory and explicitly releasing it using the free() function when it is no longer needed.

Jsmon helps security teams identify these types of architectural risks by mapping out the external assets that might be running vulnerable software versions. When a developer forgets to manage this heap memory correctly, the door opens for Use-After-Free vulnerabilities.

What is a Use-After-Free (UAF) Vulnerability?

A Use-After-Free vulnerability occurs when an application continues to use a pointer after the memory it points to has been freed. In a typical lifecycle, a program allocates memory, uses it, and then frees it. However, if the program fails to clear the pointer (setting it to NULL) after calling free(), that pointer becomes what is known as a "dangling pointer."

If the program later attempts to read from or write to that dangling pointer, it is accessing memory that has been returned to the system's memory allocator. This memory might have already been re-allocated for a different purpose, containing entirely different data or even executable instructions. Accessing this "stale" reference can lead to crashes, data corruption, or, in the worst-case scenario, Remote Code Execution (RCE).

The Lifecycle of a UAF Bug

  1. Allocation: The program requests a block of memory on the heap (e.g., ptr = malloc(32);).
  2. Freeing: The program releases the memory back to the heap manager (e.g., free(ptr);).
  3. Dangling Pointer: The variable ptr still holds the memory address, even though that address is no longer reserved for it.
  4. Use: The program attempts to access the memory via ptr (e.g., strcpy(ptr, "data");).

Technical Breakdown: How UAF Works in C/C++

Let's look at a simplified technical example of a vulnerable C program. This snippet demonstrates how a dangling pointer can be manipulated.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct User {
    char name[16];
    void (*print_info)(char*);
};

void default_print(char* name) {
    printf("User: %s\n", name);
}

int main() {
    struct User* user1 = (struct User*)malloc(sizeof(struct User));
    strcpy(user1->name, "Alice");
    user1->print_info = default_print;

    printf("Allocated user1 at %p\n", user1);

    // Freeing the memory
    free(user1);
    printf("user1 freed.\n");

    // At this point, user1 is a dangling pointer.
    // An attacker might trigger a new allocation here.

    char* malicious_data = (char*)malloc(sizeof(struct User));
    strcpy(malicious_data, "EVIL_PAYLOAD_HERE");
    printf("Allocated malicious_data at %p\n", malicious_data);

    // Vulnerable Use: The program still uses user1
    user1->print_info(user1->name);

    return 0;
}

In the example above, if malicious_data is allocated the exact same memory block that user1 previously occupied, the attacker can overwrite the print_info function pointer. When the program calls user1->print_info(user1->name), it will execute whatever address the attacker placed in that memory slot.

The Dangling Pointer Problem

The core of the UAF issue is the dangling pointer. In complex software like web browsers or kernel drivers, tracking the ownership of memory is incredibly difficult. A single object might be referenced by dozens of different modules. If one module frees the object while another still holds a reference to it, a UAF is born.

Modern heap allocators (like glibc's malloc or Windows' ntdll heap) try to optimize performance by reusing recently freed memory blocks. This behavior, while efficient, is exactly what attackers exploit. If an attacker can predict which memory block will be reused, they can "groom" the heap to place their own data into the spot formerly occupied by a legitimate object.

How Attackers Exploit Use-After-Free

Exploiting a UAF is often a multi-step process involving memory layout manipulation and control flow hijacking.

Heap Grooming and Spraying

To exploit a UAF, the attacker must ensure that the memory freed by the application is filled with their controlled data before the application "uses" the dangling pointer again. This is achieved through Heap Grooming.

Heap grooming involves making a series of specific allocations and deallocations to put the heap into a predictable state. In a web browser, this might be done using JavaScript to create thousands of strings or arrays. If the attacker knows the size of the freed object, they can allocate many objects of that same size, increasing the probability that one of their objects will occupy the freed slot.

Heap Spraying is a related technique where the attacker fills large portions of the heap with a NOP sled and shellcode, making it easier to redirect execution to a known memory range if they manage to hijack a pointer.

Overwriting Function Pointers and VTables

In C++, objects often contain a VTable (Virtual Table) pointer. The VTable is a lookup table used to resolve function calls at runtime. If an attacker can use a UAF to overwrite an object's VTable pointer, they can point it to a "fake" VTable they have constructed in memory. When the program calls a virtual method on the freed object, it will look up the function address in the attacker's fake table and jump to malicious code.

Real-World Examples of UAF Vulnerabilities

Use-After-Free vulnerabilities are not just theoretical; they have been the root cause of some of the most significant security breaches in history.

CVE-2019-5786 (Google Chrome)

In 2019, Google disclosed a high-severity UAF vulnerability in the FileReader component of Chrome. Attackers were able to use this bug to escape the browser sandbox and execute arbitrary code on the underlying operating system. The vulnerability was exploited in the wild before a patch could be issued, highlighting how valuable UAF bugs are to sophisticated threat actors.

Linux Kernel UAFs

UAF vulnerabilities are frequently discovered in the Linux Kernel, often within network drivers or filesystem code. Because the kernel runs with the highest privileges, a UAF here can allow a local user to escalate their privileges to root. A common pattern involves freeing a socket object but failing to remove it from a list of active connections, allowing an attacker to interact with the freed socket memory via subsequent system calls.

The Impact of UAF Exploitation

The impact of a successful Use-After-Free exploit ranges from annoying to catastrophic:

  1. Denial of Service (DoS): The most common result is a simple application crash. While less severe than RCE, it can still disrupt critical services.
  2. Information Disclosure: An attacker might be able to read sensitive data (like encryption keys or passwords) that was placed in the memory block after it was freed.
  3. Privilege Escalation: As seen in kernel exploits, UAF can allow a restricted user to gain administrative control.
  4. Remote Code Execution (RCE): By hijacking function pointers or VTables, attackers can execute arbitrary commands, giving them full control over the target system.

How to Detect and Prevent Use-After-Free

Preventing UAF requires a combination of disciplined coding, automated testing, and modern language features.

Defensive Coding Practices

The simplest defense is to always set pointers to NULL immediately after freeing them. This ensures that any subsequent use of the pointer will trigger a null-pointer dereference (a safe crash) rather than a UAF.

free(ptr);
ptr = NULL; // Prevents UAF

In C++, developers should prefer Smart Pointers (like std::unique_ptr and std::shared_ptr) over raw pointers. Smart pointers use Reference Counting to ensure that memory is only freed when no more references to it exist, effectively eliminating the possibility of a dangling pointer.

Automated Tools and Sanitizers

Modern development workflows utilize powerful tools to catch UAF bugs during the testing phase:

  • AddressSanitizer (ASan): A fast memory error detector for C/C++. It instruments the code to detect out-of-bounds accesses and Use-After-Free errors at runtime.
  • Valgrind: A programming tool for memory debugging, memory leak detection, and profiling. Its memcheck tool is excellent for identifying dangling pointer usage.
  • Static Analysis: Tools like Clang Static Analyzer or specialized commercial tools can scan source code for logical patterns that lead to UAF without actually running the program.

Memory-Safe Languages

The most effective way to prevent UAF is to use memory-safe languages like Rust. Rust’s ownership model and borrow checker enforce strict rules at compile-time, ensuring that memory cannot be freed if it is still being referenced. This effectively moves the burden of memory safety from the developer to the compiler.

Conclusion

Use-After-Free vulnerabilities remain a critical threat in the cybersecurity landscape. Their ability to turn a simple logic error into a full system compromise makes them a favorite for exploit developers. While modern mitigations and memory-safe languages are making these bugs harder to exploit, the massive amount of legacy C and C++ code in existence ensures that UAF will be a relevant topic for years to come. Understanding the mechanics of the heap and the danger of dangling pointers is essential for any developer or security professional.

To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.

Read more