Finding and exploiting vulnerabilities in H.264 decoders [pdf]

https://wrv.github.io/h26forge.pdf

by goranmoomin • 3 years ago

244 57 3 years ago

wrv.github.io

_joel2• 3 years ago

It's not my field of expertise but would AFL help here, or fuzzing in general (or in before anyone says Rust)

Aissen2• 3 years ago

This is a custom-made fuzzer for H.264, in Rust, that has found many vulnerabilities. It should be released during Usenix Security 2023.

_joel2• 3 years ago

Ah great!

fasterthanlime• 3 years ago

The problem with a general-purpose fuzzer is that the H.264 format is complex - you'd end up with a lot of syntactically-incorrect files (which decoders would easily reject) whereas H26Forge is a specialized fuzzer that ends up with syntactically-correct but semantically-incorrect files, and that's how it finds actual vulns before the heat death of the universe.

Re Rust: the problem here is hardware-acceleration, as far as I can tell. Even if we had a pure Rust H.264 decoder, you'd probably still want to use whatever your hardware has to use overall fewer resources. The drivers might be the place to look, and there's some progress on that front in Android for example, but as things stand fuzzing like that is extremely valuable.

wtallis• 3 years ago

Isn't the whole claim to fame for AFL that it largely mitigates or avoids that problem by tracking branch coverage so it doesn't waste time permuting the input in ways that don't change the program behavior meaningfully?

forgotusername6• 3 years ago

Yes, fuzzing does work on decoders. I can't remember how deep AFL managed to get but I do remember a flurry of crash bugs against our decoder when somebody first tried it

brigade• 3 years ago

AFL works by trying to modify bits and seeing what branches change direction. Arithmetic coding means this relationship desyncs almost instantly, so it’s hard to mutate into interesting test cases.

Kye• 3 years ago

It looks like this also affects H.265 decoding.

wrv4• 3 years ago

We did find an H.265 issue, but the tool is not currently built to generate H.265 videos.

kevingadd• 3 years ago

I wonder if the iOS versions would have been tracked down if the researchers didn't have access to Corellium. I'm glad they did, since it sounds like a pretty nasty exploit you could trigger from almost any web page.

ikekkdcjkfke• 3 years ago

Remote fast webpage rendering as a service is what i'm looking for.

CommitSyn2• 3 years ago

You could show the user a picture of the page, but what about interaction? Seems like remote desktop would be far easier.

saagarjha2• 3 years ago

How is the stream of rendered images going to be sent to your device, though? ;)

wrv4• 3 years ago

The iOS issues were found by directly playing generated videos on an actual iPhone with iOS 13.3. The kernel panics helped guide us on where to look in Ghidra. Corellium was helpful for kernel debugging, and testing newer versions of iOS. Without Corellium, kernel debugging may have been more painful.

HeckFeck• 3 years ago

Lovely. This makes me feel even more comfortable with the amount of auto-playing video bloat on the web.

inetknght• 3 years ago

Yup. I am extremely glad I have media disabled via two different extensions and I have to enable media on both before it will load.

discovered an out-of-bounds read that causes a crash of the Firefox GPU utility process and a user-visible information leak

Is that why sometimes Firefox will go all wonky-blinky on random websites and eventually crash?

fefe23• 3 years ago

I find it funny that now fuzzers are being written in rust, as if that translates to better quality bugs being found.

It looks to me like the effort would have been better spent writing a decoder in rust. AFAIK Mozilla moved the mp4 (that's the container format often used around h264) parser in firefox to rust, but their h264 decoder is from ffmpeg (?). In the end the h264 will most likely be decoded in the gpu using closed source code by the hardware vendor.

Kudos to the team for doing smart fuzzing instead of just throwing garbage. Most fuzzing projects spend much less brain power, and usually get worse results.

steveklabnik• 3 years ago

as if that translates to better quality bugs being found.

Did anyone claim this? I can't find that claim in the paper.

padenot• 3 years ago

The mp4 demuxer is indeed in Rust [0], and runs in the content process (= the process in which the web page is loaded).

We don't have a h264 decoder in our source tree, we use the platform's decoder (because of patents). It's very often in a separate, dedicated process, and when it's not, it's in the GPU process, because when hardware accelerated decoders are used, they're using more or less the same resources as the rendering code.

Those other processes with the tightest sandbox possible (per process type, per platform, etc.), and don't have access to the web page.

On Linux, the platform decoder we're using is `libavcodec` from FFmpeg, but that's still in a separate process with a tight sandbox.

We're also doing something interesting, which is compiling libraries to WASM and then back to native code to get memory safety [1]. This is used when performance isn't critical (unlike codecs, so, e.g. a demuxer that we don't want to rewrite in Rust).

[0] https://github.com/mozilla/mp4parse-rust/ [1]: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

elFarto• 3 years ago

Those other processes with the tightest sandbox possible...

I guess I should get really around to getting the nvidia-vaapi-driver to work inside the decode sandbox, rather than requiring it to be disabled.

sroussey• 3 years ago

That RLBox idea of compiling libraries to WASM and then back to native code to get memory safety is wild!

tasty_freeze• 3 years ago

You seem to be imputing motivation for using Rust, then criticizing them for making your assumption. If they had written a fuzzer in python, would you assume they used python because they had the mistaken idea that a slower program would produce better results?

It seems like a much more likely explanation is they know Rust well and it is their tool of choice. Another possibility is that a good fuzzer is non-trivial and they appreciate the compile-time checks offered by the language to avoid an entire class of errors.

PragmaticPulp• 3 years ago

I find it funny that now fuzzers are being written in rust, as if that translates to better quality bugs being found.

I can't find any such claim in the article. It says the tools are written in Rust and Python. I don't see any claims that fuzzing with a Rust-based fuzzer produces "better quality bugs". That seems to be your own assumptions projected on to the authors?

It's more likely that the authors wrote the tools in languages they're comfortable working with. It's not surprising that security researchers would be familiar with writing Rust.

alrlroipsp• 3 years ago

The claim is in the quote itself, in their use of the expression "as if" ...

You could also call it a baseless rant.

wrv4• 3 years ago

A Rust decoder was something discussed at the start, which is why we chose the language. As research goes, we primarily focused on just the H.264 syntax elements.

The Chromium folks are working on a Rust crate called cros-codecs [1] for VP8, VP9, and H.264 parameter set parsing, with VAAPI as a back-end.

[1] https://chromium.googlesource.com/crosvm/crosvm/+/42bdf1de57...

vngzs• 3 years ago

now fuzzers are being written in rust, as if that translates to better quality bugs being found.

I'm not sure if you're being facetious, but this is a classic straw man fallacy[0]: you've constructed a nonsensical motivation for the authors' use of Rust, then argued against that motivation.

There is superficial similarity between (1) "the authors wrote the fuzzer in Rust" and (2) "the authors wrote the fuzzer in Rust because it translates to better-quality bug findings", but the paper's authors did not claim (2), nor would any reasonable person claim (2).

More likely is that Rust is a useful language for authoring fuzzers because it is fast and supports modern abstractions while eliminating multiple troublesome categories of bugs. Fast performance, zero-cost abstractions, automatic memory management, and concurrency safety are useful language properties regardless of their relevance to security bugs.

[0] https://en.wikipedia.org/wiki/Straw_man

mpol• 3 years ago

I remember stories from 20 years ago, about mplayer having security issues. These were supposedly used by people connected to the music industry to hack on people that were downloading music illegally. It felt very much as scaremongering, I didn't hear much of a followup.

In this age of video and especially video on the web, the added complexity might have accounted for even more security issues in decoders.

laserbeam2• 3 years ago

This is a pretty bad way to make an announcement. The abstract mentions iOS, Firefox, VLC and multiple Android devices.

1. At least 2 of those entries are software users CAN upgrade manually, but versions are hidden deep within the text. If users can take action that should be incredibly clear.

- I have been unable to quickly skim and find a version of Firefox has fixes for these.

- VLC has a fix for a use after free issue in 3.0.18, but I can't tell at a glance if other issues still persist.

2. Do we know anything about whether this is exploited in the wild or not? I can't tell from the abstract nor the conclusion.

The technical information is valuable, but anything actionable for users to mitigate effects is really hard to find :(.

[Edit] Ok, the disclosure and ethics subsection does mention that Apple, Mozilla and VLC have fixed these bugs in their latest releases, and Google and MediaTek are aware of the problems.

That's the bit I was hoping to find at a glance.

est312• 3 years ago

Those are fair questions but note that this is a research paper (and an excellent one at that), not a blog post meant for general audiences. The focus of the abstract and introduction sections is more higher level, on the contributions of the paper, instead of what it means for end users.

izacus• 3 years ago

A research paper should doubly avoid having such clickbait titles.

laserbeam2• 3 years ago

I fully agree it is a research paper and the subject matter is absolutely great! My complaint is the research paper hints at what may be affected in the abstract, that got picked up in the title, and then it got a challenging to find actionable details quickly for either an end user or someone only mildly interested in the topic.

It also liked to a github page which is a great place include the short non-research content. I think the github page was WIP at the time the article appeared on hn.

I know my attitude was critical, but I also tried to include that info in the message (even though I found the responsible disclosure subsection after posting my original comment). I also feel that info should be present on HN in one of the top comments for these kinds of articles (regardless of whether it's mine or someone else's).

wrv4• 3 years ago

Hi, first author here! Thanks for sharing the paper. Check out our Mastodon thread for a high level overview of our findings: https://infosec.exchange/@wrv/110081590177440081

Thaxll• 3 years ago

30k loc seems a lot for this kind of project.

cobbzilla• 3 years ago

Have you read the H.264 spec? 30k seems light to me

mmis1000• 3 years ago

You probably never heard about bluetooth spec. The spec grows so big to the point that no one even able to figure it out completely. And neither can you confidently say there is no bug in your implementation because reading them completely is nearly impossible. The cve database have tones of bug related to bluetooth and that is even adding up every year.

tumdum_2• 3 years ago

I thought the opposite, 30k seems small when the spec for decoding only in 800 pages.

chatmasta4• 3 years ago

There's a certain romance to the idea of a random video that looks like colorful noise actually crashing or exploiting your device. It's basically the closest thing to "snowcrash" that we have.

ChuckNorris89• 3 years ago

Could a hack be possible by exploiting the GPU? Like making a 3D game scene that's actually encoding malware so when the GPU tries to render it you now have access to the system resources?

Arrath2• 3 years ago

We do read about occasional vulnerabilities on phone GPUs, but I do have to wonder. Wouldn't the compartmentalization and difference in compute abilities between CPU and GPU inherently limit the scope to which a vulnerability on the GPU in a typical PC can exploit?

H8crilA• 3 years ago

Don't know about a scene, but EC2-like access to virtual GPUs was rumored to be pretty dangerous, potentially even to the hardware itself (think something like changing the voltages via undocumented registers). The attack surface there is enormous. It was rumors, maybe someone here knows better.

kafrofrite• 3 years ago

You can target co-processors in general, e.g., here [1], thus I assume people do hack GPUs.

Generally, the better we become in introducing mitigations, the more expensive attacks become and attackers have bosses, budgets and deadlines. They will try to find other avenues to land on a target :-)

[1]https://objectivebythesea.org/v5/talks/OBTS_v5_iBeer.pdf

jamal-kumar2• 3 years ago

It was really bad when the best way to play a video on a website was through the god damn adobe flash plugin - isn't it crazy thinking back on how that was just normal for so long? [1] [2]

People lament the loss of all those flash games and stuff but some of those sites were SKETCHY, not to mention ad networks with unchecked .swf "creatives"...

[1] http://phrack.org/issues/69/8.html#article

[2] http://phrack.org/issues/69/13.html

chatmasta4• 3 years ago

Oh yeah, I remember the "flash super cookie" being a well-known marketing technique.

You know what's really crazy? Before the Snowden revelations in 2013, something like 70% of the web was using http:// (including sites like Amazon and Facebook, IIRC - although checkout pages may have been secured). LetsEncrypt really did a great job of getting the Web past the starting line of basic security.

eru• 3 years ago

I'd hope for someone reverse engineering the brain (or a specific individual's brain), then figuring out exactly what incomprehensible colourful noise of a video to show you, and at the end you mysteriously know how to speak Cantonese.

mannyv• 3 years ago

IMO any complicated protocol or format will be subject to crashing bugs because just verifying correct behavior is difficult.

To discover bugs, just build the xyz file yourself. People tend to use tools to generate content, and those tools generally don't make invalid content. That's a general problem with qa/verification.

Finding and exploiting vulnerabilities in H.264 decoders [pdf]

Related Stories