We hope that researchers and developers will build upon H26Forge to greatly improve the video decoder system.

Contributions are most welcome! If you find any issues in decoders using H26Forge, let us know and we’ll add it to our Trophies section :)

If you’d like to know more about this work, check out our paper, to appear at USENIX Security: https://wrv.github.io/h26forge.pdf .

I’ll also be presenting this at Black Hat if you’d like to chat there! https://www.blackhat.com/us-23/briefings/schedule/index.html#the-most-dangerous-codec-in-the-world-finding-and-exploiting-vulnerabilities-in-h-decoders-33272

(3/3)

Not only can H26Forge generate videos, it can also modify existing ones to produce targeted spec non-compliant videos.

Why? Because sometimes you just need a PoC, and manually modifying H.264 encoded videos is miserable. With H26Forge, you can just write Python scripts that transform video syntax elements. We give more of the motivation in https://github.com/h26forge/h26forge/blob/main/docs/MOTIVATION.md

We include some starter scripts in the codebase, including those for generating the PoC videos described in our paper.

(2/3)

Atop all these issues, we also find a nifty use-after-free in FFmpeg in VLC for Windows, alongside issues all across the hardware decoder ecosystem! This was so much fun to work on with @stevecheckoway and @hovav .

You can read more details in our paper available here: https://wrv.github.io/h26forge.pdf .

Keep a lookout for the release of H26Forge so more security researchers can also find these types of bugs!

Returning to the CVE-2022-22675 RCA, our starting point was that an out-of-bounds cpb_cnt_minus1 can overwrite other members in the decoder struct.

Given our familiarity with H.264, we found that overwriting the syntax element that controls the number of reference pictures could likely lead to a second overflow.

At a high level, we achieve a heap overflow by:
1. Ordering the bitstream so that structs we want to overflow are in memory.
2. Triggering CVE-2022-22675 to overwrite the number of reference pictures.
3. Using the overwritten number of reference pictures in a Slice that calls parsePredWeightTable
4. Injecting an intentional decoding failure at the point we want to stop writing.
5. Using multiple slices to write arbitrary length values at an attacker chosen offset.

CVE-2022-32939 is a standard buffer overflow in the H.264 bitstream reader that can only be triggered with a long-enough correctly encoded bitstream. It enables a skip-then-write primitive in the kernel, and is triggerable from video thumbnailing. Patched in iOS 15.7.1 and 16.1 and iPadOS 15.7.1 and 16.

CVE-2022-42846 is a denial-of-service from undefined behavior when passed in an H.264 IDR Inter predicted slice, also triggerable from video thumbnailing. Patched in iOS and iPadOS 15.7.2 and 16.2.

CVE-2022-42850 is a heap overflow in the H.265 SPS parsing. While H26Forge does not support H.265 video generation, the syntax elements use the same entropy-encoding so we implemented just the SPS portion. This heap overflow allows us to overwrite an object with a virtual destructor, giving us control of the program counter once a video stops playing.

For each of these, we create a video transform that takes in an input video and modifies the syntax elements to exercise the relevant features.

We first found CVE-2022-3266, an information leakage vulnerability in Firefox patched in version 105.

Frame size information can be found in both the Sequence Parameter Set (SPS) of an encoded H.264 video, as well as the MP4 file it’s muxed into. In Firefox, we found that an SPS frame size larger than the MP4 frame size led to a crash of the GPU process from an out-of-bounds read.

This was okay though; Firefox fell back to its software decoder to parse and play the video. We found that the frame size from the initial SPS is used for the lifetime of the video, so a second SPS with smaller frame size than the first causes the rest of the frame to be filled with uninitialized data, resulting in information leakage from xul.dll.

To explore the security of H.264 decoders, we create H26Forge: around 30,000 lines of Rust code allowing security researchers to (1) generate entropy-encoded videos with out-of-bounds semantics that strictly follow the H.264 syntax, and (2) programmatically edit the syntax elements using video transforms while correctly re-encoding the videos.

By testing these randomly generated spec non-compliant videos on different decoders, we found some fun vulnerabilities. By programmatically editing H.264 videos we created proof of concept videos to exploit the vulnerabilities.

Video codecs are a marvel of hidden complexity, allowing for all the fun video applications we have today. The H.264 specification is around 800 pages of rules that specify how to decode videos. But with hidden complexity comes hidden security risk.

The H.264 codec works by finding similarities between and across video frames, then sending instructions on how to recreate the image at an end-point. These instructions are known as syntax elements, and values they take on the semantics. The values are entropy-encoded using algorithms like exp-Golomb, CABAC, or CAVLC.