Heap of Trouble: Dissecting the Integer Overflow in LibHyperHTTP (CVE-2024-13337)

In the world of embedded devices, every byte counts. That's why libraries like LibHyperHTTP exist—stripped down, fast, and theoretically efficient. It powers everything from smart toasters to industrial control gateways. But as we know, 'efficient' C code often translates to 'unsafe' C code.

The vulnerability we're dissecting today, CVE-2024-13337, is a classic tale of trusting the client. The library attempts to parse incoming HTTP headers by calculating their total size to allocate a buffer. It sounds simple enough: read the length of the name, read the length of the value, add them up, and malloc.

Unfortunately, the developers forgot that computers have limits on how high they can count. By carefully crafting an HTTP request with specific header lengths, we can trick the server into allocating a buffer the size of a peanut, then trying to stuff a watermelon inside it. The result? A spectacular heap overflow that gives us control over the application's execution flow.

The root cause resides in the http_process_headers function. The code iterates through incoming headers and maintains a total_size variable. The fatal mistake was declaring total_size as a standard uint32_t and performing addition without checking for overflows.

When the processor adds two 32-bit integers that sum to more than 4,294,967,295, the value wraps around to 0 (or a small number). This is the 'Integer Overflow'.

Here is the logic flaw in plain English: The code calculates needed_size = header_len + value_len. If we send a header with a length of 0xFFFFFFF0 and a value of 0x20, the result isn't a massive number—it wraps around to 0x10 (16 bytes). The allocator sees a request for 16 bytes and happily obliges. However, the subsequent memcpy operation uses the original source lengths, copying gigabytes of data into that tiny 16-byte slot. Boom.

Let's look at the smoking gun. Below is a simplified view of the vulnerable C code compared to the patched version. It's a textbook example of why SafeInt libraries exist.

The Vulnerable Code

// The 'total_len' variable is a 32-bit unsigned integer
uint32_t total_len = 0;
 
for (int i = 0; i < header_count; i++) {
    // VULNERABILITY: No check for overflow here!
    total_len += headers[i].name_len + headers[i].value_len;
}
 
// We allocate based on the wrapped value
char *buffer = malloc(total_len);
 
// But we copy based on the actual data... Heap corruption ensues.
serialize_headers(buffer, headers);

The Fix

The vendor patched this by implementing a saturation check (or "clamping") before the addition. If the addition would exceed the maximum value, it errors out immediately.

uint32_t total_len = 0;
 
for (int i = 0; i < header_count; i++) {
    uint32_t current_len = headers[i].name_len + headers[i].value_len;
    
    // The Fix: Check if adding current_len would wrap around
    if (total_len > UINT32_MAX - current_len) {
        return HTTP_ERROR_TOO_LARGE;
    }
    
    total_len += current_len;
}
 
char *buffer = malloc(total_len);

[!NOTE] It is terrifyingly common to see this specific pattern in C networking libraries. Always check your boundaries.

Exploiting this on a modern system requires bypassing mitigations like ASLR and NX, but the overflow gives us a powerful primitive: a linear heap overflow of arbitrary length and content.

Here is the attack strategy:

1. Heap Feng Shui: We send several legitimate requests to fragment the heap, positioning a vtable (virtual function table) or a function pointer structure immediately after the chunk we intend to overflow.
2. The Trigger: We send the malicious request with the wrapped length. The allocator places our tiny buffer right before the target object we identified in step 1.
3. The Overwrite: The memcpy blows past the end of our buffer, overwriting the adjacent object's function pointers with addresses we control.
4. Execution: When the application tries to use that adjacent object (e.g., logging the request), it jumps to our shellcode (or ROP chain).

This isn't theoretical. In our testing environment, we achieved a consistent crash within milliseconds and a working shell within 4 hours of analysis.

If you are using LibHyperHTTP, you need to patch immediately. The vendor has released version 2.4.1 which includes the overflow checks. There are no configuration changes that can mitigate this, as the vulnerability is in the core parsing logic.

Immediate Steps:

1. Identify: Scan your firmware or dependency manifest for libhyperhttp.so or static linkage.
2. Patch: Upgrade to v2.4.1 or later.
3. WAF: If you cannot patch immediately, configure your WAF to drop HTTP requests with abnormally large header definitions (e.g., > 16KB), although this is a cat-and-mouse game against the overflow math.

For developers writing C/C++: stop doing raw arithmetic on lengths derived from user input. Use compiler built-ins like __builtin_add_overflow or safe wrapper classes. If you think "it won't happen to me," you're next.