*Published: June 2024*

Overview

A critical vulnerability, CVE-2024-45490, was discovered in the popular XML parsing library, libexpat, affecting versions before 2.6.3. This flaw is in the xmlparse.c file, specifically related to the XML_ParseBuffer function not properly rejecting negative buffer lengths. This issue can lead to unexpected behavior and opens up the potential for denial-of-service (DoS), memory corruption, or even remote code execution under specific scenarios.

In this post, we’ll break down what CVE-2024-45490 is, walk through the affected code, and see how an attacker could potentially exploit it. Links to sources and references are provided at the end.

What is libexpat?

libexpat is one of the most widely used low-level C libraries for parsing XML. Lots of other software, from web servers to embedded systems, rely on it for handling XML data safely.

The Root of the Issue

The primary problem is that, up until version 2.6.3, libexpat’s XML_ParseBuffer() function in xmlparse.c does not correctly check if the input buffer length is negative.

Normally, the function expects a non-negative integer indicating how much data to parse. If a negative value sneaks in and isn’t blocked, it can be (depending on the system and compiler) interpreted as an extremely large unsigned integer when performing memory operations—leading to buffer overruns, memory corruption, or program crashes.

Here is a simplified excerpt of the faulty logic from xmlparse.c

// xmlparse.c (before 2.6.3)

int XML_ParseBuffer(XML_Parser parser, int len, int isFinal) {
    // 'len' should be >= , but is not checked!
    if (!parser->buffer) {
        // allocate buffer...
    }
    // Vulnerability: Negative 'len' is not rejected
    memcpy(parser->buffer, input_data, len); // WHAT IF len <  ??
    // ...rest of code
}

If len is negative, memcpy is called with a massive (unsigned) size due to type conversion, smashing memory and causing unpredictable behavior.

Patch Fix

As of libexpat 2.6.3, a check ensures that negative lengths are immediately rejected:

// xmlparse.c (after fix)

int XML_ParseBuffer(XML_Parser parser, int len, int isFinal) {
    if (len < ) {
        // Immediately reject negative size
        return XML_STATUS_ERROR;
    }
    // safe to continue...
    memcpy(parser->buffer, input_data, len);
}

Let’s imagine a web server parses XML uploads like this (pseudo-code)

void handle_upload(const char* xml, int size) {
    XML_Parser parser = XML_ParserCreate(NULL);
    XML_ParseBuffer(parser, size, 1);
}

If there’s no check to ensure size >= and a malicious client uploads an empty file, but through protocol trickery causes size == -1, then:

XML_ParseBuffer(parser, -1, 1);
// Internally: memcpy(parser->buffer, xml, xffffffff); // 4 GB!

Crash the server (DoS)

- Overwrite critical data structures if lucky/unlucky

C code invoking the buggy function with a negative length

#include <expat.h>
#include <stdio.h>

int main() {
    XML_Parser parser = XML_ParserCreate(NULL);
    char *input = "<root></root>";
    int len = -42;
    // Directly triggering the vulnerability
    if (XML_ParseBuffer(parser, len, 1) == ) {
        printf("Parsing error: %s\n", XML_ErrorString(XML_GetErrorCode(parser)));
    } else {
        printf("Parse maybe succeeded, but memory could be corrupted!\n");
    }
    XML_ParserFree(parser);
    return ;
}

Impact

- Denial of Service (DoS): Crashes server/services using libexpat.

Potential Memory Corruption: May lead to heap, stack, or data section corruptions.

- Potential Code Execution: Chaining further bugs could possibly execute code, especially on embedded or custom builds.

References

- [CVE-2024-45490 [NIST NVD]](https://nvd.nist.gov/vuln/detail/CVE-2024-45490)
- libexpat 2.6.3 Release Notes
- libexpat Project Page
- Technical Discussion on oss-security mailing list

Conclusion

CVE-2024-45490 shows how even simple mistakes—like missing a check for negative numbers—can have huge impacts in C projects that handle memory directly. If you use libexpat anywhere in your projects, upgrade right now and always double-check your own input validations. These small details can mean the difference between safe, stable software and a system that attackers can control.

If you want to learn more, check out the references or dig into the libexpat source!

Timeline

Published on: 08/30/2024 03:15:03 UTC
Last modified on: 09/04/2024 14:28:19 UTC