On June 16, 2023, a new vulnerability was disclosed affecting the open source DWG library, LibreDWG. Catalogued as CVE-2023-36273, this issue impacts LibreDWG up to version .12.5. Let’s break down in simple terms what’s going on, why it’s important, and how attackers could potentially exploit it.

What is LibreDWG?

LibreDWG (https://www.gnu.org/software/libredwg/) is a C library that handles DWG files, which are popular file formats used by AutoCAD for storing building plans, blueprints, and other design schematics. Many open-source CAD tools and backend services use LibreDWG to read and write these files.

Where’s the Problem? (bit_calc_CRC in bits.c)

The issue lies in the CRC (Cyclic Redundancy Check) calculation code—specifically in the function bit_calc_CRC located in the file bits.c. This function is called to verify data integrity when reading parts of a DWG file. The problem: it can cause a *heap buffer overflow*, potentially letting attackers run arbitrary code or crash apps using the library.

Code Snippet: Vulnerable Function

Here’s a simplified version of the problematic function based on upstream source (see LibreDWG source):

uint32_t
bit_calc_CRC (const unsigned char *buf, unsigned int len)
{
  uint32_t crc = xFFFFFFFF;
  for (unsigned int i = ; i < len; i++)
  {
    unsigned char index = (unsigned char)(((crc) & xff) ^ *buf++);
    crc = (crc >> 8) ^ crc_table[index];
  }
  return ~crc;
}

The vulnerability occurs if len is very large (or not well-checked), and buf points to a memory area that’s smaller than len—leading to reading and processing memory after the end of the buffer. In some situations, this overflow can be weaponized to overwrite other heap memory, paving the way for code execution.

How Could This Be Exploited?

By carefully crafting a malformed DWG file, an attacker could trigger an out-of-bounds read (and potentially write) in programs using LibreDWG v.12.5 or older. If the memory layout is favorable, this could:

(In some situations) Achieve remote code execution within the app’s context

This is particularly dangerous if the target application processes user-supplied DWG files—for example, design-sharing platforms, automated CAD conversion tools, or cloud-based renderers.

Example Attack Scenario

1. An attacker creates a DWG file where a section header or object contains invalid length fields, tricking LibreDWG into setting len longer than the actual buffer.

The app opens that file and invokes bit_calc_CRC on the section, overrunning the heap buffer.

3. Depending on heap state, further memory may be corrupted or application logic altered, potentially leading to arbitrary code execution.

Proof-of-Concept (PoC)

While actual exploit code would depend on the app’s usage of LibreDWG, here’s what a test harness might look like:

// WARNING: FOR EDUCATIONAL PURPOSES ONLY!
const unsigned char small_buf[2] = {x41, x42};
unsigned int dangerous_len = 10000;  // Way larger than 2
// This calls bit_calc_CRC to read 10000 bytes from small_buf!
// This overflows past the end of small_buf, touching lots of heap memory
bit_calc_CRC(small_buf, dangerous_len);

In real attacks, the buffer could hold manipulated DWG data inside an actual file.

How Can It Be Fixed?

The maintainers have patched this in later versions. If you use LibreDWG, upgrade to the latest version immediately. Avoid ever calling bit_calc_CRC (directly or indirectly) with unchecked lengths or with untrusted data.

Code-wise, robust bounds-checking should be added

if (len > buffer_size) return ERROR; // Or handle gracefully

See the release notes and patches for specific changes.

References

- GNU LibreDWG official website
- LibreDWG GitHub repository
- Debian Security Tracker — CVE-2023-36273
- NIST NVD entry

Final Thoughts

Heap buffer overflows like CVE-2023-36273 continue to demonstrate why careful input validation and bounds checking are critically important, especially in libraries handling complex binary formats. If you manage an application using LibreDWG and allow user uploads, treat this vulnerability as urgent.

Timeline

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