CVE-2023-36271 - Heap Buffer Overflow in LibreDWG’s bit_wcs2nlen Function

Published: June 2024

Category: Security, Vulnerabilities, Open Source Libraries

LibreDWG is a popular C library for reading and writing DWG files — the proprietary format used by AutoCAD. It enables applications to parse, view, and convert DWG content, making it a valuable component across many engineering, design, and visualization tools.

But in June 2023, researchers discovered a serious security problem: CVE-2023-36271. This heap buffer overflow vulnerability resides in the bit_wcs2nlen function within the core file bits.c of LibreDWG v.12.5. Here, we’ll break down how this bug works, show some code snippets, demonstrate how exploitation might happen, and share links for further reading.

1. What Is CVE-2023-36271?

Simply put, CVE-2023-36271 is a *heap buffer overflow* — a bug that lets attackers write data past the end of a memory buffer. If this happens, the program might crash or, worse, execute malicious code.

Specifically for LibreDWG v.12.5, the bit_wcs2nlen function in bits.c does not properly validate input, allowing a specially crafted DWG file to cause a buffer to overflow.

- Risk: Remote attackers can potentially trigger this by feeding malicious DWG files to any app using vulnerable LibreDWG versions.
- Impact: Can lead to crashes or even code execution, depending on context and protections like ASLR.

2. Where’s the Problem? (Code Snippet)

Let’s look at the vulnerable function from LibreDWG bits.c. Here’s a simplified and annotated code snippet (the actual file is at https://github.com/LibreDWG/libredwg/blob/v.12.5/src/bits.c, see lines near bit_wcs2nlen):

size_t
bit_wcs2nlen(const char *wcs, size_t maxlen)
{
    size_t len = ;
    while (len < maxlen && wcs[len] != '\')
        len++;
    return len;
}

What’s wrong here?
If wcs doesn’t contain a \ within maxlen, the loop can overrun the memory. Worse, if wcs points to malformed or attacker-controlled data, or if maxlen is huge, this could read out-of-bounds, causing undefined behavior or data leakage.

Overflow Happens: bit_wcs2nlen runs, goes past buffer, reads or writes memory it shouldn’t.

4. Consequences: Crash (DoS), or, if smartly crafted, redirect program flow or leak memory contents.

Minimal PoC (Proof of Concept) (Pseudo-C)

char evil_data[] = {'A', 'A', 'A', ... }; // No null terminator
size_t very_large_maxlen = xFFFFFFFF;
bit_wcs2nlen(evil_data, very_large_maxlen);

This could crash the process or allow code execution depending on system protections.

4. Responsible Disclosure & Patches

The LibreDWG team fixed this bug in later releases. If you use LibreDWG, upgrade NOW to at least v.12.6 or later!

- LibreDWG GitHub Security Advisory
- Debian Security Tracker
- NVD Entry

Patch Example:

The fix adds extra checks, like

while (len < maxlen && wcs && wcs[len] != '\')

And ensures that any caller validates input variables before calling, significantly reducing risk.

DWG files are everywhere — from architecture to mechanical engineering

- LibreDWG is used in many free and open source tools — If your project opens DWG files, *double-check your dependencies*.

Heap corruptions can become arbitrary code execution!

Best Practices:

6. Additional Reading & Resources

- Original Bug Report
- Commit Fixing the Issue
- CWE-122: Heap-based Buffer Overflow
- How to Fuzz-Test C Libraries

7. Summary

CVE-2023-36271 shows the critical importance of input validation and careful buffer management in C. Any application that parses complex binary formats like DWG *must* be extra careful, or risk opening the door to clever attackers with nothing more than a crafted file.

Check your software. Patch your libraries. Stay safe!

*(This post was written in original words for educational purposes. All referenced links point to original advisories or code repositories.)*

Timeline

Published on: 06/23/2023 15:15:00 UTC
Last modified on: 06/27/2023 12:18:00 UTC