CVE-2024-50602 - How a Bug in libexpat (Before 2.6.4) Can Crash Your App – Deep Dive & Exploit Example

---

Libexpat is a well-known C library used for parsing XML. Many projects use it under the hood, from popular Linux tools to commercial software. In June 2024, a vulnerability was discovered and published as CVE-2024-50602. This bug allows an attacker to crash an application by sending carefully crafted XML, exploiting a logic error in internal state management. Here, I’ll break down what happened, why it matters, and show you a proof-of-concept crash.

What is CVE-2024-50602?

It’s a bug in libexpat versions before 2.6.4. The issue is with the way the parser handles “resuming” and “stopping” through the XML_ResumeParser and XML_StopParser functions. A parser that hasn’t started yet can be interrupted by XML_StopParser, then if you call XML_ResumeParser, the library crashes. This can be used for denial of service (DoS).

The Expat security advisory is here:
- Upstream expat bug tracker
- GitHub advisory

Technical Details: Understanding the Crash

The usual lifecycle for an Expat parser works a bit like this:

Create a parser object

- Call start/stop/resume as your process XML data

Clean up

The bug is a logic slip: if you attempt to "stop" a parser *before* any parsing actually starts (the parser is "unstarted"), and then attempt to "resume" it, the internal state is inconsistent, leading to a crash (typically segmentation fault). This can be abusive if an attacker has control over parser functions, maybe through bindings in a larger application.

Affected function: XML_ResumeParser (called after XML_StopParser on an unstarted parser)

Here’s a simple C snippet that triggers the bug using libexpat before 2.6.4

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

int main() {
    // Create the parser but don't parse anything yet
    XML_Parser parser = XML_ParserCreate(NULL);

    // Stop the parser (while it's still unstarted)
    XML_StopParser(parser, XML_TRUE);

    // Now, try to resume the parser - this triggers the crash
    // (Don't do this in production code!)
    XML_ResumeParser(parser);

    // Cleanup
    XML_ParserFree(parser);
    return ;
}

Expected result:
This code will crash (segmentation fault or abort) on affected libexpat versions.

Why Does It Happen?

The function XML_StopParser() sets the parser state, even if the parser has not begun parsing any data. Later, XML_ResumeParser() expects the parser to be in a state consistent with having been started, leading to out-of-bounds writes or dereference of null pointers.

Impact: Who Can Exploit This?

- Local attackers: If your program exposes a plugin or FFI interface, a malicious user controlling the parser logic can crash your service.
- Remote attackers: Less likely, but possible if your parser interface can be controlled over the network.
- Denial of Service (DoS): This is not an RCE (remote code exec), but a crash that can halt services.

- Download latest

- https://github.com/libexpat/libexpat/releases
- 2.6.4 release notes

Distribution packages:

- Fedora: CVE-2024-50602 Bugzilla
- Debian/Ubuntu users: update via package manager

If you can’t update:

Summary Table

| | Before 2.6.4 | 2.6.4 and After |
|----------------|---------------|--------------------|
| Crash possible | Yes | No |
| Patch status | Not fixed | Fixed |

Conclusion

CVE-2024-50602 is a subtle but effective way to bring down programs using vulnerable versions of libexpat. While it won’t let attackers run code, it can DoS services that depend on strict XML parsing flows. If your software or distribution uses libexpat, upgrading to 2.6.4 should be a priority.

References

- libexpat GitHub Issue #810
- CVE-2024-50602 NVD page
- Expat Release Notes


If you maintain software that parses XML, check your dependencies now. Not all bugs let hackers in—but even a crash is sometimes all it takes to cause major headaches.

Timeline

Published on: 10/27/2024 05:15:04 UTC
Last modified on: 10/30/2024 18:35:16 UTC