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.
Here's a better summary: ffmpeg is getting DDOS'd by AI generated security CVEs. Those CVEs currently have zero real-world impact; the "researchers" didn't even bother to write a patch/fix for their reports.
My hot-take: it's security theater drama. Burn-out maintainers on one side and wealthy corporate employees on the other.
Even if they have real-world impact: ffmpeg is a volunteer project. With (ffmpeg -codecs | wc -l) 519 codecs. This will trivially exhaust available ffmpeg eng resources.
There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?
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.
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.
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.
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.
VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux
ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.
If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.
If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.
Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.
Depends if any important websites are re-compressing user-uploaded videos. If there's a website converting user-uploaded gifs to mp4 to save on bandwidth or something, I wouldn't be surprised if they used ffmpeg to do it.
FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?
> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.
But it was a product using a 9 year old ffmpeg build (at the time).
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.
"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.
>I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.
Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.
If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.
> The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.
That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
Nah, it's entitlement to expect maintainers to overwork and fix every single "security" issue thrown their way. ffmpeg has just a few resources and Google has way, way more. The maintainers are not your servants nor are they Google's servants.
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.
IIRC, his "LibAV" fork was malicious and his people lied a lot to the community ("ffmpeg is now deprecated!"). Ultimately, they failed, but I see a lot of their rhetoric and resentment in Kostya's post today.
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.
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.
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)
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.
Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?
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.
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".
FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1].
On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain.
On the other hand, we have plenty of evidence that untrusted input validation bugs pose a very high risk to end users. So, for as long as this is their policy, FFmpeg code really should not be included in any system where security is at all important. Perhaps we need a "fundamentally unsafe for use" sticker for OSS projects taking this stance?
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.
If FFmpeg with current developer resources is not good or secure enough for their use case. They should implement their own code that is. I feel that is most reasonable approach for anybody using it.
Not sure why the Twitter account is complaining about this now. Maybe it's part of a bigger sequence of issues? This particular one was resolved pretty quickly, back in August.
This seems very weird to me as someone who has been watching vulnerability reports for over 8+ years.
Normally if a bug is found in a open source project, then its common courtesy to propose a patch to fix it. Hell when you do red team security research on a codebase your supposed to identify the root cause in code or human behavior and propose a fix/patch if you have access to the code.
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.
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.
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).
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 because it isn't likely to be exploited doesn't mean it isn't there. While it'd be nice if Google contributed, if I had to choose between Google doing this and doing nothing, I'd choose this.
> Is it really the job of a volunteer working on hobby 1990s codec to care about Google's security issues? Or anyone's?
It isn't "Google's security issues", it's a FFmpeg security issue. The tone from this account is incredibly childish.
This exchange was what shocked me the most:
Person 1:
> If someone sends me cutekitten.mp4, but it is actually not an mp4 file, but a smush file using an obscure 1990s hobby codec, could the bug be exploited if I just run ffplay cutekitten.mp4?
FFmpeg:
> Is it the job of volunteers working on game codecs in their free time as a hobby to fix Google's AI generated bug reports?
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)
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.
Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.
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.
If a volunteer-run project wants to be full of CVEs and inevitably bleed users because of it, fine, but to whine about someone reporting a CVE in the first place is ridiculous. I'm not annoyed they haven't fixed it, I'm annoyed they're complaining about the problem being acknowledged.
I help maintain a popular open source project. It's bad enough getting reports from human idiot "researchers" who have no understanding of the attack surface nor what constitutes a vulnerability, and are just spamming their bullshit to try to collect worthless CVEs.
But now Google using the full power of their AI to do the same? Fuck off.
"Don't be evil" is long dead and buried. These worthless corporations taking and taking and rarely giving back, and even if they do it's poisoned.
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.
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.
> Recieving vuln reports is a gift.
A real gift would be to include a patch for it. Not just to run off into the sunset.
[flagged]
Here's a better summary: ffmpeg is getting DDOS'd by AI generated security CVEs. Those CVEs currently have zero real-world impact; the "researchers" didn't even bother to write a patch/fix for their reports.
My hot-take: it's security theater drama. Burn-out maintainers on one side and wealthy corporate employees on the other.
Even if they have real-world impact: ffmpeg is a volunteer project. With (ffmpeg -codecs | wc -l) 519 codecs. This will trivially exhaust available ffmpeg eng resources.
There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?
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.
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".
Does this mean we have to run vlc in a sandbox while watching a downloaded film?
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.
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.
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.
But you don't need to use a popular codec, because all codecs are enabled by default.
VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux
ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.
If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.
If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.
Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.
Depends if any important websites are re-compressing user-uploaded videos. If there's a website converting user-uploaded gifs to mp4 to save on bandwidth or something, I wouldn't be surprised if they used ffmpeg to do it.
VLC and ffmpeg share the same underlying library family (libav*) where this vulnerability lives.
> I doubt it'd be worth one's time to write exploits for desktop Linux
How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.
FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?
I'm certain it's happened but since I don't have one off the top of my head I'll instead point out a related issue: https://en.wikipedia.org/wiki/Stagefright_(bug)
It's worth pointing out that many, many, many things use the libav* library family.
Does this count?
https://signal.org/blog/cellebrite-vulnerabilities/
> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.
But it was a product using a 9 year old ffmpeg build (at the time).
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
"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
I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.
The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.
>I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.
Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.
If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.
> The person who makes the software has the duty to fix the security issues in their own code, nobody else, no matter how big they are.
That’s just clearly untrue for freely available software. So every person that ever published a hobby project on GitHub has a duty to fix security issues in it?
The organisation who ships software to paying customer may have a duty to fix security issues. If they didn’t, it could be seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.
It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.
Nah, it's entitlement to expect maintainers to overwork and fix every single "security" issue thrown their way. ffmpeg has just a few resources and Google has way, way more. The maintainers are not your servants nor are they Google's servants.
YouTube made $36.7 billion last year. Time they started pulling their weight.
Perhaps it'll be sooner than you expect: actually having proper fixes made by AI for the issues found with AI.
Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/
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"
I'm not sure if Kostya's account is truthful. He has a huge axe to grind against ffmpeg https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
IIRC, his "LibAV" fork was malicious and his people lied a lot to the community ("ffmpeg is now deprecated!"). Ultimately, they failed, but I see a lot of their rhetoric and resentment in Kostya's post today.
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.
He sounds bitter.
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.
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)
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.
Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?
“This is broken, here’s how I fixed it”
Vs “this is broken, you gave 90 days to fix it”
If you can’t see the difference you’re the existential threat to Free software that stems from the trillion dollar industries that just take.
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...
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.
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".
FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1].
On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain.
On the other hand, we have plenty of evidence that untrusted input validation bugs pose a very high risk to end users. So, for as long as this is their policy, FFmpeg code really should not be included in any system where security is at all important. Perhaps we need a "fundamentally unsafe for use" sticker for OSS projects taking this stance?
[1] https://x.com/FFmpeg/status/1984425167070630289
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
I edited my post to make the nature of the requested payment clearer.
https://xcancel.com/ffmpeg/status/1984207514389586050
If FFmpeg with current developer resources is not good or secure enough for their use case. They should implement their own code that is. I feel that is most reasonable approach for anybody using it.
Those who do not learn from Stagefright are doomed to repeat it.
https://en.wikipedia.org/wiki/Stagefright_(bug)
Not sure why the Twitter account is complaining about this now. Maybe it's part of a bigger sequence of issues? This particular one was resolved pretty quickly, back in August.
The Google bug report is dated August 21: https://issuetracker.google.com/issues/440183164
There are FFmpeg commits apparently fixing the sanm codec problem within a day or so: https://github.com/FFmpeg/FFmpeg/commits/140fd653aed8cad774f...
Earlier, on August 20, there are FFmpeg fixes for other issues in the same codec apparently also found by Google (by fuzzing not AI?): https://github.com/FFmpeg/FFmpeg/commit/5f8cb575e83a05bc95b8..., https://github.com/FFmpeg/FFmpeg/commit/e726f7af17b3ea160b6c...
Why didn’t one of the ffmpeg developers that Google employs fix the bug?
I assume Google has several full time ffmpeg developers given how much they rely on it.
This seems very weird to me as someone who has been watching vulnerability reports for over 8+ years.
Normally if a bug is found in a open source project, then its common courtesy to propose a patch to fix it. Hell when you do red team security research on a codebase your supposed to identify the root cause in code or human behavior and propose a fix/patch if you have access to the code.
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.
Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?
Please stop spreading this misinformation. At least in Debian this is enabled by default (and as another post indicates, Ubuntu as well).
Run the following command to confirm:
ffmpeg -codecs|grep sanm
Then they can certainly afford to supply patches.
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.
> FFmpeg would present a warning
Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.
>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
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.
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 because it isn't likely to be exploited doesn't mean it isn't there. While it'd be nice if Google contributed, if I had to choose between Google doing this and doing nothing, I'd choose this.
> Is it really the job of a volunteer working on hobby 1990s codec to care about Google's security issues? Or anyone's?
It isn't "Google's security issues", it's a FFmpeg security issue. The tone from this account is incredibly childish.
This exchange was what shocked me the most:
Person 1:
> If someone sends me cutekitten.mp4, but it is actually not an mp4 file, but a smush file using an obscure 1990s hobby codec, could the bug be exploited if I just run ffplay cutekitten.mp4?
FFmpeg:
> Is it the job of volunteers working on game codecs in their free time as a hobby to fix Google's AI generated bug reports?
Completely dodging the question.
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)
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.
Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.
> If you don't want people to use your software to make money, release it with a license that prohibits that.
Or, y'know, the project could balk at a trillion dollar company expecting them to do free work.
Cuts both ways.
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.
Google never asked a volunteer for a fix.
This is part of Google’s standard disclosure policy: it gets disclosed within 90 days starting from confirmation+contact.
If ffmpeg didn’t want to fix it, they could’ve just let the CVE get opened.
It's not just Google who could be affected by this.
> and then expect volunteers to provide them fixes.
Expect volunteers to provide everyone using the software with fixes.
For a bug in the LucasArts Smush codec? Why didn't you verify it was an mp4/h264 first?
Mp4 is an envelope codec, so it could be both an mp4 and an obscure codec
Kindly do the needful and update ticket in Jira when complete.
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.
This is a volunteer-run open source project. Your expectations are unrealistic and, to be quite frank, offensive.
What are their expectations, and which are unrealistic?
It reads to me like the only expectation is civility, not even necessarily an expectation of fixing it.
If Google can identify a vulnerability, what should they do? If they don't report it, they're effectively stockpiling weapons.
I'd wager that every usage of ffmpeg in Google infra is sandboxed, so calling this "Google's problem" seems silly to me.
Google can't be responsible for fixing everyone's sloppy C code.
If a volunteer-run project wants to be full of CVEs and inevitably bleed users because of it, fine, but to whine about someone reporting a CVE in the first place is ridiculous. I'm not annoyed they haven't fixed it, I'm annoyed they're complaining about the problem being acknowledged.
Yeah, I mean if it's an actual vulnerability what are they complaining for?
You get what you pay for.
I help maintain a popular open source project. It's bad enough getting reports from human idiot "researchers" who have no understanding of the attack surface nor what constitutes a vulnerability, and are just spamming their bullshit to try to collect worthless CVEs.
But now Google using the full power of their AI to do the same? Fuck off.
"Don't be evil" is long dead and buried. These worthless corporations taking and taking and rarely giving back, and even if they do it's poisoned.
Because not disclosing an actual bug that could affect users would somehow be good?
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 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