Live data from Hacker News

FFmpeg dealing with a security researcher

twitter.com

61–70 of 174 posts

Re: FFmpeg dealing with a security researcher

#61

"Just send patches" is I think the main point. Rather than just reporting security bugs these big organisations ought to start seeing the point of open source being that can and should be contributing if they value the project and need this fixed because its a pretty obscure problem generated by AI.

I can't help but be reminded about the time that an MS employee put in a ticket on FFmpeg's bug tracker and said it was 'High priority'.[1][2]

On the one hand, this one Microsoft employee was probably in a bind and actually blocked by this bug. On some level, it's hard to blame them as an individual.

On the other hand, Microsoft has no leverage here and pays somewhere between a pittance and nothing for FFmpeg, while getting enormous use out of it. If they regularly donated with either money or patches, then there'd be no beef, but it's the expectation of getting something more for free while already getting so damn much for for zero cents that really grinds both mine and FFmpeg's gears.

That reminds me that I should probably throw some money at FFmpeg, if only to clear my conscience.

[1] https://xcancel.com/FFmpeg/status/1775178805704888726

[2] https://news.ycombinator.com/item?id=39912916

Re: FFmpeg dealing with a security researcher

#62
post #51

Earlier quoted context omitted.

They do.

Full build with all the codecs, or a custom build with a limited vetted set?

Does it matter?

Like, I don't expect Google to deliver patches for FFmpeg beyond bug fixes or features that directly benefit them, but that's the least you can expect.

Re: FFmpeg dealing with a security researcher

#63
post #34
post #2

It looks like the FFmpeg account on X is calling out Google for using AI to mass-report CVEs in obscure volunteer maintained codecs, then expecting unpaid maintainers to rush fixes. Large, profitable firms rely on FFmpeg everywhere, but don’t seem to be contributing much to the project.

You think google uses ffmpeg for youtube?

They did once upon a time atleast.[1] Most videos probably go through dedicated hardware nowadays, but it wouldn't surprise me if some videos still have to go the FFmpeg route that catches all the videos that the dedicated hardware can't handle.

[1] https://web.archive.org/web/20110315155125/https://multimedi...

Re: FFmpeg dealing with a security researcher

#64
post #6

[flagged]

So, this is the report they complained about: https://issuetracker.google.com/issues/440183164

I don't know how a vulnerability report could be much better than that. It is a real vulnerability. The report includes a detailed analysis of where the vulnerability is. The bug has been validated, and the report includes exact reproduction instructions.

How is that a bullshit bug report?

Re: FFmpeg dealing with a security researcher

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

I think that the x264 and hevc codecs are much more battle tested and a 0day for them would be worth enough that nobody would bother using it on random torrenters.

Re: FFmpeg dealing with a security researcher

#66
post #62
post #51

Earlier quoted context omitted.

Full build with all the codecs, or a custom build with a limited vetted set?

Does it matter? Like, I don't expect Google to deliver patches for FFmpeg beyond bug fixes or features that directly benefit them, but that's the least you can expect.

It matters to Google if they process public submitted videos using FFmpeg codecs that can be exploited.

One would expect Google to only use FFmpeg with vetted codecs and to either reject videos with codecs that have untrusted FFmpeg modules or to sandbox any such processing, both for increased safety and perhaps to occassionally find new malware "in the wild".

Re: FFmpeg dealing with a security researcher

#67
post #56
post #53

Earlier quoted context omitted.

If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs. In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.

To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).

Yeah but who cares about them, right? It's a volunteer project don't you know.

Re: FFmpeg dealing with a security researcher

#68
post #59

Earlier quoted context omitted.

it’s very… sad, i guess, watching a lot of software engineering discourse on social media (at least, what I see from Twitter) just become this attention grabbing shitposting. ffmpeg is very much a big player in this field, and it has paid off handsomely - those tweets are often popular on site, and shared across other social media.

> paid off handsomely Paid off how? Did they get more funding? More contributors?

"exposure"

Re: FFmpeg dealing with a security researcher

#69
post #29

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

It would be nice if they helped fix it, and maybe they don't help enough in general?, but as ffmpeg says this specific codec is just a hobby project for ancient obscure files. **Google gains zero value from this codec.** Disabling it would be plenty to fix the problem on their end.

But that would leave everyone else vulnerable, so they report it. Reporting real problems is a good thing.

Re: FFmpeg dealing with a security researcher

#70
I'm confused, on the bug report it is claimed ffmpeg fixed the issue, so presumably it was a valid issue. So what's the problem here? That it was a mere memory corruption bug and not an exploitable issue? Even still it seems reasonable that google reports bugs even if they aren't security issues and it seems reasonable to err on the side of memory cirruption being security relavent.

Edit: i guess its not even that, they are just bitter that they have to fix bugs in their own code??? Recieving vuln reports is a gift. If ffmpeg doesnt like it maybe google should just start practising full disclosure.

Post reply on HN