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

131–140 of 216 posts

Re: Twenty One Zero-Days in FFmpeg

#131

Post by lionkor »

imjonse wrote: post #129
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.…

The obvious question is, how many of those were the sort that writing in a memory-safe language would make impossible? They should prompt one of the more adventurous LLMs to find security bugs and with some luck it will deviate from the prompt and rewrite ffmpeg in Rust.

Rewriting ffmpeg in Rust will not solve it. The parts that are memory unsafe in ffmpeg, and similar projects, are not unsafe because C or C++ is inherently unsafe. Instead, it's the CODE that is unsafe. Translating the code (data structures, logic, etc) to Rust does not fix bugs in the code. That code will be littered with "unsafe" code, and of course, it will no longer be maintainable.

Re: Twenty One Zero-Days in FFmpeg

#132

Post by jstanley »

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

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up.

They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used.

I was left wondering whether they were oblivious to the fact that an attacker who can supply a video file to you is free to use whatever video codec they want? It wouldn't matter if the developers thought the codec was never used at all; if it is still available then an attacker can use it.

Or was I just missing something? Is there a good reason why vulnerabilities in this codec are not a big deal after all?

Re: Twenty One Zero-Days in FFmpeg

#133

Post by defrost »

jstanley wrote: post #132
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.…

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up. They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used. I was left w…

Big pipeline fat data users of ffmpeg can and do build their own executables that only include the top N codecs, that eliminates minor bug in obscure never used format problems pretty thoroughly.

Re: Twenty One Zero-Days in FFmpeg

#135

Post by m4rtink »

jstanley wrote: post #132
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.…

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up. They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used. I was left w…

Is it really available in practice ? Eg. do major distros even compile ffmpeg with these obscure codecs or you need to recompile it yourself to get it ?

Re: Twenty One Zero-Days in FFmpeg

#136

Post by franga2000 »

jstanley wrote: post #132
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.…

Some of the ffmpeg developers were on Lex Fridman's podcast recently, and the topic of security came up. They were talking about how there was a vulnerability in an extremely niche codec that is only used for one video game from the 90s or something, and were saying that the person who reported the vulnerability was acting like it was a big deal but it's really not because this codec is hardly ever used. I was left w…

The user is not free to use whatever codec they want. Many niche codecs can't be put into the usual containers, so if you only accept QuickTime/MP4 and AVI, sometimes even just by limiting the file extension, those codecs can't be used.

If your service works by taking whatever file the user gives you and shoving it into unsandboxed ffmpeg, you've already fucked up. It would be nice if you could do that, but that's not a guarantee ffmpeg has ever provided, nor would it make sense for them to spend their limited resources on it.

Re: Twenty One Zero-Days in FFmpeg

#137

Post by codedokode »

simjnd wrote: post #127
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.…

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?

Re: Twenty One Zero-Days in FFmpeg

#138

Post by cryo32 »

codedokode wrote: post #137
simjnd wrote: post #127

Earlier quoted context omitted.

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?

No. They tried that with coreutils and look what happened. More CVEs.

99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.

Re: Twenty One Zero-Days in FFmpeg

#139

Post by ivanjermakov »

codedokode wrote: post #137
simjnd wrote: post #127

Earlier quoted context omitted.

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?

Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance.

https://news.ycombinator.com/item?id=43140614

Re: Twenty One Zero-Days in FFmpeg

#140

Post by throwaway2037 »

lostglass wrote: post #55
woodruffw wrote: post #31

Earlier quoted context omitted.

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.

    > 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.
I am confused.

    > The MP3 format is now patent-free and requires no licensing fees to distribute or use. Fraunhofer IIS and Technicolor officially terminated their MP3 licensing programs, with all core patents having expired. Anyone can encode, decode, and distribute MP3 files or software without paying royalties.
Ref: https://forum.gamemaker.io/index.php?threads/do-you-still-ha...

Ref: https://www.reddit.com/r/gamedev/comments/5stq8z/mp3_licensi...

Ref: https://www.audioblog.iis.fraunhofer.com/mp3-software-patent...

Post reply on HN