8 ms·

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

244 points by goranmoomin 4y ago

kevingadd 4y 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 4y ago
  Remote fast webpage rendering as a service is what i'm looking for.
  - CommitSyn 4y ago
    You could show the user a picture of the page, but what about interaction? Seems like remote desktop would be far easier.
    - toast0 4y ago
      image maps[1] [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/map https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
      - CommitSyn 4y ago
        How would you know where to define all the maps for all the buttons, links, text fields, etc on apps that need to be used?
  - saagarjha 4y ago
    How is the stream of rendered images going to be sent to your device, though? ;)
- wrv 4y 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.
_joel 4y ago
It's not my field of expertise but would AFL help here, or fuzzing in general (or in before anyone says Rust)
- Aissen 4y 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.
  - _joel 4y ago
    Ah great!
- fasterthanlime 4y 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 4y 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?
    - tumdum_ 4y ago
      How do you know *ahead of time* which mutation of input will result in new path in code? You don’t. What you can do deduplicate possible inputs for mutation based on the branches taken/path.
Kye 4y ago
It looks like this also affects H.265 decoding.
- wrv 4y ago
  We did find an H.265 issue, but the tool is not currently built to generate H.265 videos.
HeckFeck 4y ago
Lovely. This makes me feel even more comfortable with the amount of auto-playing video bloat on the web.
- inetknght 4y 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 :O Is that why sometimes Firefox will go all wonky-blinky on random websites and eventually crash?
fefe23 4y 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 4y ago
  > as if that translates to better quality bugs being found. Did anyone claim this? I can't find that claim in the paper.
  - deleted 4y ago
    [deleted]
- padenot 4y 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/ https://github.com/mozilla/mp4parse-rust/ [1]: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
mpol 4y 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.
laserbeam 4y 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.
- est31 4y 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 4y ago
    A research paper should doubly avoid having such clickbait titles.
    - Aissen 4y ago
      What is clickbait here ? They found new vulnerabilities, reproduced old ones, across various products, and crafted an exploit.
  - laserbeam 4y 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).
wrv 4y 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 https://infosec.exchange/@wrv/110081590177440081
Thaxll 4y ago
30k loc seems a lot for this kind of project.
- cobbzilla 4y ago
  Have you read the H.264 spec? 30k seems light to me
- mmis1000 4y 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_ 4y ago
  I thought the opposite, 30k seems small when the spec for decoding only in 800 pages.
chatmasta 4y 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.
- eru 4y 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.
- ChuckNorris89 4y 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?
  - Arrath 4y 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?
    - chatmasta 4y ago
      Compartmentalization might make chaining the exploit more difficult, but it's certainly not unheard of. There have been exploit chains in the past that manage to jump from the baseband to the main CPU, for example. One of my favorite exploits [0] was from Project Zero where the chain began with a vulnerability in the Apple wireless stack (Broadcom? maybe, but that might be a different exploit I'm thinking of), and ended in arbitrary kernel RCE. In other words, it was "a wormable radio-proximity exploit which allows me to gain complete control over any iPhone in my vicinity." More relevantly to your question, here's a writeup about exploiting a GPU. [1] [0] https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html?m=1 https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-c... [1] https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html?m=1 https://googleprojectzero.blogspot.com/2020/09/attacking-qua...
mannyv 4y 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.

244 points by goranmoomin 4y 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 4y ago
Remote fast webpage rendering as a service is what i'm looking for.
- CommitSyn 4y ago
  You could show the user a picture of the page, but what about interaction? Seems like remote desktop would be far easier.
  - toast0 4y ago
    image maps[1] [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/map https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
    - CommitSyn 4y ago
      How would you know where to define all the maps for all the buttons, links, text fields, etc on apps that need to be used?
- saagarjha 4y ago
  How is the stream of rendered images going to be sent to your device, though? ;)
wrv 4y 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.

_joel 4y ago

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

Aissen 4y 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.
- _joel 4y ago
  Ah great!
fasterthanlime 4y 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 4y 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?
  - tumdum_ 4y ago
    How do you know *ahead of time* which mutation of input will result in new path in code? You don’t. What you can do deduplicate possible inputs for mutation based on the branches taken/path.

Kye 4y ago

It looks like this also affects H.265 decoding.

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

HeckFeck 4y ago

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

inetknght 4y 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 :O Is that why sometimes Firefox will go all wonky-blinky on random websites and eventually crash?

fefe23 4y 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 4y ago
> as if that translates to better quality bugs being found. Did anyone claim this? I can't find that claim in the paper.
- deleted 4y ago
  [deleted]
padenot 4y 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/ https://github.com/mozilla/mp4parse-rust/ [1]: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

mpol 4y 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.

laserbeam 4y 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.

est31 4y 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 4y ago
  A research paper should doubly avoid having such clickbait titles.
  - Aissen 4y ago
    What is clickbait here ? They found new vulnerabilities, reproduced old ones, across various products, and crafted an exploit.
- laserbeam 4y 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).

wrv 4y 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 https://infosec.exchange/@wrv/110081590177440081

Thaxll 4y ago

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

cobbzilla 4y ago
Have you read the H.264 spec? 30k seems light to me
mmis1000 4y 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_ 4y ago
I thought the opposite, 30k seems small when the spec for decoding only in 800 pages.

chatmasta 4y 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.

eru 4y 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.
ChuckNorris89 4y 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?
- Arrath 4y 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?
  - chatmasta 4y ago
    Compartmentalization might make chaining the exploit more difficult, but it's certainly not unheard of. There have been exploit chains in the past that manage to jump from the baseband to the main CPU, for example. One of my favorite exploits [0] was from Project Zero where the chain began with a vulnerability in the Apple wireless stack (Broadcom? maybe, but that might be a different exploit I'm thinking of), and ended in arbitrary kernel RCE. In other words, it was "a wormable radio-proximity exploit which allows me to gain complete control over any iPhone in my vicinity." More relevantly to your question, here's a writeup about exploiting a GPU. [1] [0] https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-click-radio-proximity.html?m=1 https://googleprojectzero.blogspot.com/2020/12/an-ios-zero-c... [1] https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html?m=1 https://googleprojectzero.blogspot.com/2020/09/attacking-qua...

mannyv 4y 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.