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.
They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.
The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.
It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.
The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.
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...
"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 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.
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?
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?
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.
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.
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.
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.
The buggy code in question was never in a release -- it just existed in the ffmpeg git repo: 7.1.2 does not have it at all, and it was fixed before the 8.0 release. Why does it even have a CVE?
18 comments
[ 2.5 ms ] story [ 36.6 ms ] threadThey run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.
The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.
It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.
The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.
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...
> 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.
https://en.wikipedia.org/wiki/Stagefright_(bug)
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
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 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...
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.
I assume Google has several full time ffmpeg developers given how much they rely on it.