Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty One Zero-Days in FFmpeg

depthfirst.com

Post reply on HN
Print view View original

31–40 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#31

Post by woodruffw »

skupig wrote: post #24
nemothekid wrote: post #3

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

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

Re: Twenty One Zero-Days in FFmpeg

#33

Post by nerdsniper »

zerobees wrote: post #19

Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…

Is GStreamer a more secure alternative or does it just get a bit less attention than ffmpeg?

Re: Twenty One Zero-Days in FFmpeg

#35

Post by bawolff »

naturalmovement wrote: post #30
zerobees wrote: post #19

Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…

[flagged]

> nearly inexhaustible supply of LLM slop daily,

Actual well written vulnerability reports are not the same as slop.

AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.

Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.

Re: Twenty One Zero-Days in FFmpeg

#36

Post by jeffbee »

bayouborne wrote: post #21

What about VLC's own built-in versions of decoding libraries (I think, from the FFmpeg project)? Is there a scenario here where we may have to deal with malicious MP4 files?

All media containers are potentially hostile. Any offset, extent, or reference has to be considered hostile user-provided input.

Re: Twenty One Zero-Days in FFmpeg

#37

Post by naturalmovement »

bawolff wrote: post #35
naturalmovement wrote: post #30

Earlier quoted context omitted.

[flagged]

> nearly inexhaustible supply of LLM slop daily, Actual well written vulnerability reports are not the same as slop. AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop. Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation.

> AI slop is a real problem and annoying. Just because it exists does not mean every vulnerability report is AI slop.

Ok but who is going to sift through it all to triage the good bits when you're working on something for free?

> Ffmpeg devs are free not to care, but then they cant complain when they start to get a bad reputation

Who gives a shit about reputation when you're the only game in town?

There is nothing out there that even attempts to approximate an ffmpeg clone. They are the Swiss army knife of media encoding and all complainers have produced are plastic sporks.

Re: Twenty One Zero-Days in FFmpeg

#38

Post by insanitybit »

loeg wrote: post #23
zerobees wrote: post #19

Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…

They're also extremely hostile to security researchers who report these issues.

https://x.com/ffmpeg/status/2039115531744334180?s=46&t=qCSkw...

Security is the punch line for ffmpeg.

Re: Twenty One Zero-Days in FFmpeg

#40

Post by [deleted] »

zerobees wrote: post #19

Ffmpeg has an exceptionally terrible track record when it comes to security. People have been throwing fuzzers at it for as long as I remember and coming back with a nearly inexhaustible supply of memory corruption bugs. Here's an effort by one Googler a decade ago: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-... So, while it's a demo of the capabilities of LLMs, this should not be at all surprising.…

[deleted]
Post reply on HN