Matthew GreenExploiting H.264 video decoders, yikes. https://wrv.github.io/h26forge.pdf
Cassandrich@matthew_d_green Which decoder was vulnerable? If not ffmpeg, why is anyone using anything but ffmpeg? If ffmpeg, uhg.
amos@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!