[HN Gopher] Finding and exploiting vulnerabilities in H.264 deco...
___________________________________________________________________
Finding and exploiting vulnerabilities in H.264 decoders [pdf]
Author : goranmoomin
Score : 210 points
Date : 2023-03-29 12:25 UTC (10 hours ago)
(HTM) web link (wrv.github.io)
(TXT) w3m dump (wrv.github.io)
| chatmasta wrote:
| 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 wrote:
| 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?
| kafrofrite wrote:
| 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
| Arrath wrote:
| 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 wrote:
| 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-c...
|
| [1]
| https://googleprojectzero.blogspot.com/2020/09/attacking-
| qua...
| Arrath wrote:
| Thank you! Not my area but I do love reading about it.
| chatmasta wrote:
| Same... the people at Project Zero are basically
| magicians. I love reading their write-ups, even if I
| barely understand most of them.
| H8crilA wrote:
| 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.
| jamal-kumar wrote:
| 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
| chatmasta wrote:
| 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.
| jamal-kumar wrote:
| Oh yeah arp spoofing or just session hijacking your way
| into people's accounts was way too facile back then. I seem
| to recall a browser plugin that did it [1]
|
| [1] https://en.wikipedia.org/wiki/Firesheep
| nibbleshifter wrote:
| Firesheep proliferated quite rapidly at my uni, even to
| extremely non technical people due to its sheer ease of
| use and the potential for comedy.
|
| The worst people would usually do is leave a vaguely
| embarrassing status on your FB page, which was the usual
| prank if you left your computer unlocked anyway.
| fefe23 wrote:
| 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.
| vngzs wrote:
| > 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
| wrv wrote:
| 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...
| steveklabnik wrote:
| > as if that translates to better quality bugs being found.
|
| Did anyone claim this? I can't find that claim in the paper.
| [deleted]
| padenot wrote:
| 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 wrote:
| > 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 wrote:
| That RLBox idea of compiling libraries to WASM and then back
| to native code to get memory safety is wild!
| tasty_freeze wrote:
| 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 wrote:
| > 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 wrote:
| The claim is in the quote itself, in their use of the
| expression "as if" ...
|
| You could also call it a baseless rant.
| _joel wrote:
| It's not my field of expertise but would AFL help here, or
| fuzzing in general (or in before anyone says Rust)
| fasterthanlime wrote:
| 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 wrote:
| 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_ wrote:
| 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.
| Aissen wrote:
| 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 wrote:
| Ah great!
| brigade wrote:
| 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.
| forgotusername6 wrote:
| 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
| kevingadd wrote:
| 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 wrote:
| Remote fast webpage rendering as a service is what i'm looking
| for.
| CommitSyn wrote:
| You could show the user a picture of the page, but what about
| interaction? Seems like remote desktop would be far easier.
| toast0 wrote:
| image maps[1]
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/ma...
| wrv wrote:
| 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 wrote:
| Lovely. This makes me feel even more comfortable with the amount
| of auto-playing video bloat on the web.
| inetknght wrote:
| 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?
| mpol wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| A research paper should doubly avoid having such clickbait
| titles.
| Aissen wrote:
| What is clickbait here ? They found new vulnerabilities,
| reproduced old ones, across various products, and crafted
| an exploit.
| laserbeam wrote:
| 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).
| est31 wrote:
| > 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 see. When I made the reply it already linked to the pdf.
| So you can't really be blamed neither can I. Such confusion
| is normal when a link changes.
|
| > I know my attitude was critical, but I also tried to
| include that info in the message
|
| To be fair, hn is renown for that attitude. Some of the
| most famous hn comments are precisely of that kind :)
| https://news.ycombinator.com/item?id=9224
|
| The paper was written to suit an academic audience first,
| which includes people reading it 20 years later. Actionable
| advice for users is then in accompanying notices.
|
| Also, usually when papers get published, it's months after
| they have been submitted so _usually_ security bugs are
| already fixed and if you are on somewhat up-to-date patch
| levels, you are safe. I say usually because some vendors
| might not be as quick to patch or it might not be as easy
| to fix bugs (say bugs in hardware or such).
| Kye wrote:
| It looks like this also affects H.265 decoding.
| wrv wrote:
| We did find an H.265 issue, but the tool is not currently built
| to generate H.265 videos.
| Thaxll wrote:
| 30k loc seems a lot for this kind of project.
| tumdum_ wrote:
| I thought the opposite, 30k seems small when the spec for
| decoding only in 800 pages.
| mmis1000 wrote:
| 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.
| cobbzilla wrote:
| Have you read the H.264 spec? 30k seems light to me
| wrv wrote:
| 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
___________________________________________________________________
(page generated 2023-03-29 23:00 UTC)