Summary
CVE-2023-36239 is a buffer overflow vulnerability found in libming, an open-source library used for creating and parsing SWF (Shockwave Flash) files. Specifically, the bug exists in version .4.7 of the listswf tool, within the parseSWF_DEFINEFONTINFO() function in parser.c. This vulnerability can be abused to crash the program or possibly execute malicious code. In this article, we'll dive deep into what the flaw looks like, how it's triggered, and why it's risky—with code samples and links to key resources to learn more.

What Is libming and listswf?

libming is a C library to manipulate Macromedia Flash files (SWF), widely used for extracting, generating, and analyzing Flash content. Although Flash is now deprecated on the web, tools like listswf are still used to inspect old SWF files.

The listswf utility provided by libming reads SWF files and prints out their structure, shapes, tags, and other info.

What Happens in CVE-2023-36239?

The vulnerability lives in the parseSWF_DEFINEFONTINFO() function of parser.c. This code is responsible for parsing the DEFINEFONTINFO tag inside SWF files.

A key part of this parsing involves reading a string ("FontName") from the SWF file into a fixed-size buffer. If the SWF file claims the string is longer than the buffer, the code still copies everything, leading to a classic buffer overflow.

Here’s a simplified version of the buggy code in parseSWF_DEFINEFONTINFO()

void parseSWF_DEFINEFONTINFO(SWF_parser *p, int length) {
    char fontName[256];
    int fontNameLen = get_byte(p);

    // Vulnerable part: no check that fontNameLen <= sizeof(fontName)
    fread(fontName, fontNameLen, 1, p->file);
    fontName[fontNameLen] = '\';  // Potential out-of-bounds write!
    // ...do something with fontName...
}

What's wrong here?
If fontNameLen is greater than 256, fread() will overwrite the buffer. And the line assigning fontName[fontNameLen] = '\' can write even further outside the buffer, causing memory corruption.

How Can This Be Exploited?

A specially crafted SWF file can provide a malicious length for the font name string. For instance, it can set fontNameLen to 300, causing the program to write well beyond the 256-character buffer.

Execution of injected code (if attacker can control what’s in the overwritten memory)

Proof of Concept (PoC):

Here’s a simple hexadecimal patch you could add to an SWF file

[... normal SWF data ...]
x30  // DEFINEFONTINFO tag code
x2D  // Tag length: 45 bytes (just as an example)
x90  // Font ID
x2C  // FontName length: 300!
[300 bytes of junk here...]
[... rest of SWF ...]

Running listswf with this file would trigger the bug.

Impact

- Denial of Service (DoS): The most obvious risk is an immediate crash when parsing malicious files.
- Code Execution: Given the right memory conditions and with a crafted SWF, a determined attacker might gain code execution, especially on systems with no stack protections.

How Was It Fixed?

libming's GitHub Pull Request #220 fixed this by adding a check to prevent fontNameLen from exceeding the buffer size.

Fixed code snippet

if (fontNameLen >= sizeof(fontName)) {
    // Handle error—don't continue
    return;
}
fread(fontName, fontNameLen, 1, p->file);
fontName[fontNameLen] = '\';

What Should You Do?

- If you use libming or listswf, make sure you update to libming .4.9 or later.

References

- CVE-2023-36239 at CVE.org
- libming Issue #219—Buffer overflow in parser.c
- libming commit fixing the bug
- Flash SWF File Format documentation

Final Words

While the SWF format may seem like a thing of the past, legacy tools and libraries like libming are still in use. This vulnerability is a reminder: even "read-only" utilities can hide dangerous bugs. Always keep your libraries up-to-date and never trust input files if you don't need to!

Timeline

Published on: 06/22/2023 19:15:00 UTC
Last modified on: 06/29/2023 20:58:00 UTC