>The reach of this bug is what makes it serious. Any deployment that points FFmpeg at an attacker-influenced RTSP URL is exposed: media ingest pipelines fetching user-supplied stream URLs, surveillance and CCTV systems pulling RTSP feeds, and transcoding services processing remote AV1-over-RTP sources
Wow this is actually pretty serious - I'm even surprised its being published. There are several services where I can imagine this is exploitable today.
Some people might suggest it’s crucial to publish if you’re aware of a serious vulnerability, so that people using the software in a vulnerable way can take steps to mitigate the risk.
You would also need some sort of ASLR leak to make this exploitable
Speaking from firsthand experience: codec and other media processing libraries are some of the easiest software to find address leaks in.
(There are a number of reasons for this, not least being that C makes it very easy to ship partially initialized memory over the wire.)
Speed and security are not good bedfellows. Combine that with really shitty standards and dozens of years of development...
Oh, and licensing. Licensing is the real killer. I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.
Ref: https://www.reddit.com/r/gamedev/comments/5stq8z/mp3_licensi...
Ref: https://www.audioblog.iis.fraunhofer.com/mp3-software-patent...
Sorry I was painting a broad image. I'm also worried about copyright infringement, discovery, someone switching to a different different that requires glpl, etc
I don’t think this is necessarily true! Constraints can be liberating: a language that allows strong encoding of invariants makes it easier for the language’s compiler to optimize.
I agree about long periods of development and difficult standards, though.
ffmpeg has stated many many times that they don't care about bug or security reports
[dead]