>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.

▲

akerl_ 7 hours ago | parent | next [-]

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.

▲

skupig 7 hours ago | parent | prev | next [-]

You would also need some sort of ASLR leak to make this exploitable

▲

woodruffw 6 hours ago | parent [-]

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.)

▲

lostglass 5 hours ago | parent [-]

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.

	▲	woodruffw 3 hours ago \| parent [-]
		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.

▲

TiredOfLife an hour ago | parent | prev | next [-]

ffmpeg has stated many many times that they don't care about bug or security reports

▲

huflungdung 8 hours ago | parent | prev [-]

[dead]