[HN Gopher] FFmpeg Dealing with a Security Researcher
___________________________________________________________________
FFmpeg Dealing with a Security Researcher
Author : trollied
Score : 43 points
Date : 2025-11-01 20:59 UTC (2 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| cebert wrote:
| 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.
| TheChaplain wrote:
| 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...
| cebert wrote:
| 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.
| kvemkon wrote:
| > FFmpeg would present a warning
|
| Reminds me of gstreamer plugins being separated in "base",
| "good", "bad" and "ugly" sets.
| lukeschlather wrote:
| 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.
| vreg wrote:
| 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.
| tkfoss wrote:
| Those decoders aren't even compiled and activated in the
| released binaries. But in any case, why would that be FFMPEGs
| problem?
| chris_wot wrote:
| Then they can certainly afford to supply patches.
| PaulKeeble wrote:
| "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.
| _flux wrote:
| Perhaps it'll be sooner than you expect: actually having proper
| fixes made by AI for the issues found with AI.
| anon_oss wrote:
| 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.
| vqtska wrote:
| 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.
| chemotaxis wrote:
| 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".
| ls612 wrote:
| 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.
| plorkyeran wrote:
| 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.
| IshKebab wrote:
| Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists
| D.V.L. sanm LucasArts SANM/SMUSH video
| IshKebab wrote:
| 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.
| GaryBluto wrote:
| 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.
| fabrice_d wrote:
| 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.
| GaryBluto wrote:
| 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.
| sillywabbit wrote:
| For a bug in the LucasArts Smush codec? Why didn't you
| verify it was an mp4/h264 first?
| paradox460 wrote:
| You get what you pay for.
| haskellshill wrote:
| Yeah, I mean if it's an actual vulnerability what are they
| complaining for?
| vreg wrote:
| This is a volunteer-run open source project. Your expectations
| are unrealistic and, to be quite frank, offensive.
| herpessimplex10 wrote:
| Kindly do the needful and update ticket in Jira when complete.
| Klonoar wrote:
| 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)
| mappu wrote:
| Kostya (ex-FFmpeg developer)'s take on the behaviour of the
| FFmpeg twitter account:
| https://codecs.multimedia.cx/2025/11/ffpropaganda/
| vreg wrote:
| He sounds bitter.
| GeekyBear wrote:
| Those who do not learn from Stagefright are doomed to repeat it.
|
| https://en.wikipedia.org/wiki/Stagefright_(bug)
| gnfargbl wrote:
| FFmpeg seem to be taking the position that their code must be
| considered insecure in production unless you pay them [1].
|
| On the one hand, that's fine; it's their project, and if attack
| surface is not a priority for them 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
| vreg wrote:
| 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.
| TZubiri wrote:
| > 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
___________________________________________________________________
(page generated 2025-11-01 23:00 UTC)