You think google uses ffmpeg for youtube?

No, this is the unfortunate reality of “ffmpeg is maintained by volunteers” and “CVE discovered on specific untrusted input”.

Google’s AI system is no different than the oss-fuzz project of yesteryear: it ensures that the underlying bug is concretely reproducible before filing the bug. The 90-day disclosure window is standard disclosure policy and applies equally to hobby projects and Google Chrome.

A quick search of the ffmpeg commit history shows google has made plenty of contributions to ffmpeg. They may or may not provide a patch for this CVE but reporting it is the first step so people can then decide what action to take (like don't compile that codec in for example)

I could see a compromise where if there are obscure codecs that may not be as secure, FFmpeg would present a warning before loading the file. This way, the user would have the option to decide whether to load the file or not. By default, potentially malicious files would not be loaded, which could prevent them from being used as part of an exploit. This seems like a reasonable compromise.

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.

>rarely anyone ever uses

It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

Perhaps it'll be sooner than you expect: actually having proper fixes made by AI for the issues found with 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

Because not disclosing an actual bug that could affect users would somehow be good?

The one nice thing is Google had submit a real bug at least.

The human idiot "researchers" will send paragraph long automatically generated extortion threats over not sending HSTS header

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?

The somewhat depressing reality is that if you're running ffmpeg on user-supplied multimedia without putting it in a bulletproof sandbox, you're just bound to have a bad time.

Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step you need to take. Maybe it's on the ffmpeg project that they don't steer people in that direction.

Trying to fix these bugs piecemeal is somewhat pointless - or at least, we've been trying for several decades, throwing a ton of manpower and compute at it, and we're still nowhere near a point where you could say "this is safe".

It isn't even like this is without precedent, the FORCEDENTRY NSO kit used the shitty old JBIG2 parser that Apple was shipping as its entry point despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.

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.

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

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.

It is absolutely Google's security issue if they use an open source project with that license:

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING....

and then expect volunteers to provide them fixes.

You get what you pay for.

Yeah, I mean if it's an actual vulnerability what are they complaining for?

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

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

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)

Nah, I think they can rant as much about it as they want, nothing is unprofessional on Twitter - have you seen the state of of it?

Actually I think they are using correctly, you are suppose to post something to provoke the most reactions you can.

But getting back to the point, I agree, it is not really a problem if you actually verified your input before blindly running ffmpeg on it - like people are not just downloading random files and running ffmpeg on it are they?! You would think if you are rolling ffmpeg into production code you would know the ins and outs of it.

Anyways I feel for those open-source maintainers, they must have so deal with so much noise.

He sounds bitter.

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.

Wow these people have a lot of free time... shouldn't they be programming?

The most interesting part of that is the admission that they used decompilers to reverse engineer the codecs. I wonder if makign that output freely available is legal.

All code should be considered potentially vulnerable, that's why we have so many layers of exploit mitigation from the compiler to the runtime environment to the overall design of the system the code is running in.

> unless you pay them

You can't pay for the software

>"FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment"

https://www.ffmpeg.org/legal.html