Matthew GreenExploiting H.264 video decoders, yikes. https://wrv.github.io/h26forge.pdf
Adam Shostack 
@matthew_d_green cc @larryosterman i remember a conversation we had about these architectures
Larry Osterman@adamshostack @matthew_d_green I was thinking about the Windows 7 multimedia threat modeling and fuzzing effort while reading this.
And of course, modern multimedia hardware makes this SO much more interesting (in Win7, much of the decoding was done in software).
Jesse Harris@matthew_d_green Just imagine when Hollywood gets the bright idea to start embedding anti-piracy malware in their movie streams.
LisPi@elforesto @matthew_d_green One annoying but simple-ish way to handle that would be to decode framesets in VMs over RPC, re-encode in another with some safe implementation of some simpler lossless codec (absurd space & IO requirements are the tradeoff here) & then re-encode that in whatever you want.
Tim Magee@matthew_d_green "Chrome developers try to avoid writing code that does no more than 2 of the following: [3 sins]." -- think they want to remove the *no* otherwise the implication is that Chrome devs are aiming for all 3 every time. Abstract does not bode well for the paper.
Stephen Checkoway@uriy @matthew_d_green Good catch. Thanks.
@stevecheckoway @matthew_d_green If only I had a pound for every time I've edited one end of a sentence and forgot the other end, I'd be guzzling boat drinks by now.
Skylar Caulfield 
@matthew_d_green isn’t h.264 no longer included in most Linux distros by default? And most sites have moved to VP-9
amos@skymtf @matthew_d_green unfortunately the latter is definitely not accurate. There's slight progress on the AV1 front but VP9 definitely doesn't have the same level of support across devices. Also the attack is really on the overall infrastructure, not any specific codec (H264/AVC just happens to be widely hardware-accelerated)
Cassandrich@matthew_d_green Which decoder was vulnerable? If not ffmpeg, why is anyone using anything but ffmpeg? If ffmpeg, uhg.
@dalias @matthew_d_green we looked at a variety. Section 5 describes bugs in Apple’s h.264 and h.265 decoders. Section 6 describes bugs in several others including ffmpeg.
author_is_stribika@dalias @matthew_d_green They found UAF in ffmpeg, and a variety of issues in others. I have no illusions about ffmpeg, it parses everything anyone ever used to represent video, and it's C + asm.
@dalias @matthew_d_green ffmpeg is as others mentioned, C+ASM so dangerous by default, but also it's a loose collection of third-party encoders/decoders — it rarely provides its own, doing essentially (de)muxing + gluing everything together (also filtering, resampling, etc. which aren't terribly relevant here)
tl;dr ffmpeg gives you access to the same hw-accelerated decoders as everyone else and those are the obscure/vulnerable bits
@fasterthanlime @matthew_d_green I've been out of the loop for a long time but historically all the interesting codecs were using maximally shared code and only a couple they didn't have native yet in the encoding direction glued random third party library code in.
C+asm in this kind of context is not dangerous by default. It's wacky use of malloc+free where all objects should have permanent lifetime with the codec context that's dangerous. Juggling malloc+free with bitstream processing = 🦇💩
Pär Björklund@dalias @fasterthanlime @matthew_d_green I would still call it dangerous by default as asm doesn't have any security features that we expect from modern languages.
Also more details to keep track of increasing the risk of getting it wrong.
No static analysis tools for asm afaik?
Also more details to keep track of increasing the risk of getting it wrong.
No static analysis tools for asm afaik?
@Paxxi @dalias @matthew_d_green I'm actually less wary of the ASM bits since afaict they're operating on fixed size buffers and are doing efficient packing/unpacking/swizzles/color conversions (but I haven't read it all!)
Re C: one of the vulnerabilities mentioned in the paper is a good old missing bounds check on a fixed-size (256) buffer — no cavalier use of malloc/free involved there!
bob
Gregory P. Smith (he/him) 
🚲🦝 @matthew_d_green I'm *very* happy to see people finally proving this and calling it out. I've assumed this to be true about codecs forever; they're just too complex.
Hardware manufacturers and their software contractors all focused primarily on performance and feature checkbox filling are the last people I trust to perform secure data handling.
Danil@matthew_d_green not related to h.264, but related to video-exploits - about year ago people "discovered" sequence of frames that hard-lock amd-gpu, it was working on any amd gpu even from webbrowser https://bugzilla.kernel.org/show_bug.cgi?id=201957
it mostly fixed by now, but there still ways to trigger it, not completely fixed
it mostly fixed by now, but there still ways to trigger it, not completely fixed