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

FFmpeg dealing with a security researcher

twitter.com

Post reply on HN
Print view View original

21–30 of 174 posts

Re: FFmpeg dealing with a security researcher

#21

Post by vreg »

lukeschlather wrote: post #11
TheChaplain wrote: post #3

The comments from the public.. Just wow we are doomed.. To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group. Then people start berating them without even knowing the full story...

Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.

If that is true then Google should be strictly sandboxing ffmpeg and filtering the input before it even gets there. A solid defense-in-depth approach would make sure it's highly unlikely this vulnerable code would be reached, and if it was, there would be effectively no impact.

They should be building ffmpeg with a minimal feature set anyway, so none of these obscure codecs end up included in the final binary.

Re: FFmpeg dealing with a security researcher

#23

Post by vreg »

GaryBluto wrote: post #8

Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…

This is a volunteer-run open source project. Your expectations are unrealistic and, to be quite frank, offensive.

Re: FFmpeg dealing with a security researcher

#24

Post by plorkyeran »

vqtska wrote: post #7

I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.

No, all the ancient video game codecs and other such things that are there for historical preservation purposes but are rarely actually used are disabled by default and you have to really go out of your way to enable them. This was originally for binary size/build time reasons.

Re: FFmpeg dealing with a security researcher

#25

Post by herpessimplex10 »

GaryBluto wrote: post #8

Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…

Kindly do the needful and update ticket in Jira when complete.

Re: FFmpeg dealing with a security researcher

#26

Post by tkfoss »

lukeschlather wrote: post #11
TheChaplain wrote: post #3

The comments from the public.. Just wow we are doomed.. To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group. Then people start berating them without even knowing the full story...

Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.

Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?

Re: FFmpeg dealing with a security researcher

#27

Post by IshKebab »

vqtska wrote: post #7

I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.

I checked with Ubuntu's ffmpeg and it is enabled by default. There are a huge list of codecs enabled by default (maybe all of them?). Given the security track record of codecs implemented in C, this means it's basically guaranteed that there are dozens of security vulnerabilities in ffmpeg.

I think the same is probably true for VLC to a lesser extent, which is pretty wild considering I've never heard of it being used as an attack vector, e.g. via torrents.

Re: FFmpeg dealing with a security researcher

#28

Post by IshKebab »

plorkyeran wrote: post #24
vqtska wrote: post #7

I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.

No, all the ancient video game codecs and other such things that are there for historical preservation purposes but are rarely actually used are disabled by default and you have to really go out of your way to enable them. This was originally for binary size/build time reasons.

Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists

   D.V.L. sanm                 LucasArts SANM/SMUSH video

Re: FFmpeg dealing with a security researcher

#29

Post by Klonoar »

GaryBluto wrote: post #8

Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…

I feel like you’re misunderstanding their point.

It’s not that the vulnerability was found and reported, it’s that a trillion plus dollar organization that no doubt actively uses ffmpeg in a litany of spaces is punting the important work of fixing it to volunteers.

This is the same issue that we’re seeing over with XSLT in Chrome: they’re happy when they’re making money off the back of these projects but balk when it comes down to supporting them.

(Yes, everyone is aware Google contributes to open source. They’re still one of the most valuable companies to ever exist, there is almost no excuse for them getting away with this trade off)

Re: FFmpeg dealing with a security researcher

#30

Post by chris_wot »

lukeschlather wrote: post #11
TheChaplain wrote: post #3

The comments from the public.. Just wow we are doomed.. To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group. Then people start berating them without even knowing the full story...

Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.

Then they can certainly afford to supply patches.
Post reply on HN