Summary:
A serious vulnerability tracked as CVE-2024-23122 has been discovered in Autodesk’s applications, related specifically to the opennurbs.dll library. By tricking a victim into opening a specially crafted 3DM file (Rhinoceros 3D model format), an attacker could trigger an Out-of-Bounds Write, crashing the program, leaking data, or even running malicious code. This post breaks down how this works, demonstrates an attack with sample code, and references original advisories.

Background

The 3DM file is widely used for 3D design (Rhinoceros). Autodesk applications use the opennurbs.dll ('OpenNURBS Toolkit') to read (parse) these files. Functions inside this DLL can be tricked into writing data outside the bounds of allocated memory when they process a malformed structure inside a 3DM file.

Why does this matter?

The Vulnerable Component

- Affected Software: Autodesk products using opennurbs.dll (including, but not limited to, Autodesk AutoCAD, DWG TrueView, etc.)
- CWE Type: CWE-787: Out-of-bounds Write
- Original Advisory: Autodesk Bulletin
- CVSS Score: NIST NVD CVE-2024-23122 (as per advisory)

How the Vulnerability Works

Inside opennurbs.dll, functions parsing geometry data expect certain lengths and structures. If a crafted 3DM file contains an intentionally broken “length” or “index” field, the code might try to write outside valid memory space.

Simplified (Pseudocode) Vulnerable Code

// vBufferLen comes from the 3DM file
void process_surface(unsigned char* data, size_t vBufferLen) {
    unsigned char buffer[256];

    // Vulnerable: No check if vBufferLen > sizeof(buffer)
    memcpy(buffer, data, vBufferLen);
    // If vBufferLen is > 256, crashes or writes outside buffer!
}

When vBufferLen is controlled by the attacker (from 3DM file content) and is greater than 256, this will cause out-of-bounds writes.

Proof-of-Concept (PoC): Generating a Malicious 3DM File

To prove this vulnerability, security researchers often create simple “crash PoC” files or minimal “shellcode” files:

Python: Generating a Malicious 3DM File

Below is a simple example in Python. This won’t produce a legitimate model, but demonstrates a way malformed lengths could be supplied.

# test_crash.3dm - Minimal PoC for CVE-2024-23122

# The opennurbs.dll expects header --> [magic bytes][length][data...]
# We put a huge length field to force overflow

with open("crash_poc.3dm", "wb") as f:
    f.write(b'3DM\x00')              # Magic: example header
    f.write((x100).to_bytes(4, 'little')) # Maliciously large length
    f.write(b'A' * x100)           # Junk data (bigger than safe buffer)

How to test:
Open this file in any vulnerable Autodesk application. If unpatched, this may crash the application, or worse (don’t do this on a production system!).

Exploit Scenario

1. Attack Setup: Attacker crafts a malicious 3DM file as shown above, possibly with added payload for deeper exploitation (code execution).

3. Trigger: File loads in Autodesk app; opennurbs.dll parses the file and triggers out-of-bounds write.
4. Impact: Program crashes; or, attacker’s code runs under victim’s privileges (e.g. dropping malware, stealing data from memory).

Mitigation & Detection

- Official Patch: Get the latest update from Autodesk

User Protection:

- Don’t open unknown/untrusted 3DM files.

Additional References

- Autodesk Security Advisory: adsk-sa-2024-0001
- CVE-2024-23122 at NVD
- OpenNURBS Toolkit
- CWE-787: Out-of-bounds Write

Conclusion

CVE-2024-23122 is a classic example of how even mature, widely used CAD software can be tripped up by unexpected file content. Always keep your 3D and CAD tools up to date, and never open model files from untrusted locations. A simple file can lead to a serious breach.

If you’re a defender:

Consider blocking .3dm files by default if not needed.

If you’re a user:

Cover your bases – vulnerabilities like this can be doorways to bigger attacks!

Stay Secure.

Timeline

Published on: 02/22/2024 02:15:49 UTC
Last modified on: 08/01/2024 13:47:05 UTC