CVE-2023-39615 - **DISPUTED** Libxml2 Out-of-Bounds Read Vulnerability Explored

In June 2023, a security advisory popped up under the name CVE-2023-39615. It talked about a vulnerability in libxml2, specifically in version 2.11., one of the most popular XML parsing libraries around. The warning said an out-of-bounds read could be triggered through the xmlSAX2StartElement() function, possibly resulting in a crash (Denial of Service, or "DoS"). The trigger? Just supply a specially-crafted XML file.

That sounds serious. But there’s a twist: the Libxml2 maintainers heavily disputed this claim, insisting their software doesn't actually support custom SAX callback interfaces anymore, and the crash could happen without any "crafted" file at all.

Let’s break it all down, see the code, and review what’s really going on — in plain language.

The Allegation

- Library: Libxml2

Vector: Parsing a bad (crafted) XML file

- CVE entry: NVD listing here
- PoC/Exploit? Yes, with minimal code (see below)

Code Dive: How Does the Crash Happen?

The original claim says: if you provide a custom set of SAX (Simple API for XML) callbacks — a legacy interface from the old days of Libxml2 — the library doesn’t check arguments properly in xmlSAX2StartElement(). A malicious file could cause the program to read memory it’s not supposed to (out-of-bounds), crashing the application.

Here's a simplified PoC (Proof-of-Concept). This code will most likely crash even without a *crafted* XML file.

#include <libxml/parser.h>
#include <libxml/SAX2.h>
#include <stdio.h>

// Define a SAX handler with only some callbacks
xmlSAXHandler broken_sax = {
    .startElement = NULL, // This is the old SAX1 interface
    // Intentionally leaving other handlers NULL
};

int main() {
    xmlParserCtxtPtr ctxt;
    ctxt = xmlCreateFileParserCtxt("example.xml");
    ctxt->sax = &broken_sax;   // Set broken handler
    xmlParseDocument(ctxt);    // This will crash!
    xmlFreeParserCtxt(ctxt);
    return ;
}

The "Crafted Input" Myth?

The original CVE said that *malicious XML could trigger this*. But, as you see above, even a totally normal XML file will crash the app, if you manually fudge the handler.

> This means the so-called "crafted input" isn't really needed!

Libxml2 Maintainers: Not Actually A Bug?

The Libxml2 maintainers (see official Libxml2 bug tracker discussion here and this patch discussion) explained:

From the NVD note

> the vendor's position is that the product does not support the legacy SAX1 interface with custom callbacks; there is a crash even without crafted input.

2. Can this be exploited for DoS?

- Yes — in silly/legacy code that builds malformed parser contexts, a user (or attacker) could crash the process with an XML file — or even just by *parsing anything at all*.

3. Is there a real security hole?

- Not really, says the vendor. If you break the API contract, bad stuff happens, but this isn't considered a "vulnerability."

Official References & Resources

- CVE Record (NVD)
- Libxml2 Project Homepage
- Libxml2 bug report: #493
- Related Libxml2 commit (fix/discussion)

Don't use custom SAX handlers unless you really know what you’re doing.

- Upgrade to the latest libxml2 version: Newer versions ignore custom (broken) handlers and don’t trigger this crash.

Final Thoughts: Is CVE-2023-39615 a "Real" Bug?

CVE-2023-39615 made waves because crashes, especially ones due to "out-of-bounds reads", usually scare people! In this case, anyone following the documented API is safe. You have to intentionally break the rules for this “vulnerability” to show up, and even then, it's just a crash — not a security takeover.

If you maintain legacy code — check it. Otherwise, sleep easy.


Did you find this useful? Share with your fellow devs — avoid “vulnerabilities” by using APIs right!


Disclaimer: This write-up is for educational purpose only. Always follow open source communities and vendor guidance for patching your systems.

Timeline

Published on: 08/29/2023 17:15:00 UTC
Last modified on: 09/06/2023 17:15:00 UTC