Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg dealing with a security researcher

twitter.com

Post reply on HN
Print view View original

151–160 of 174 posts

Re: FFmpeg dealing with a security researcher

#151

Post by bawolff »

brigade wrote: post #133
phil21 wrote: post #131

Earlier quoted context omitted.

In a past life as a managed hosting provider ffmpeg exploits were used to gain access to systems. It’s used for pretty much any platform you can upload video to. Some places far more competently than others.

See, I’d be interested in any actual evidence/writeups of that in the wild.

In fairness, i dont think the majority of actual exploits used in the wild get writeups.

Budget web host using outdated software getting hacked because they havent updated in 2 years isn't exactly all that interesting of a blog post even if the victim knows enough to figure out what happened.

Re: FFmpeg dealing with a security researcher

#152

Post by hitekker »

bawolff wrote: post #136
estimator7292 wrote: post #112

Earlier quoted context omitted.

You're completely missing the point. The problem isn't that volunteer devs are harassed into work. The problem is being harassed . Whether or not you "care" or feel the need to do any work or accept responsibility, constant harassment will destroy anyone , even you.

Getting a polite bug report is not being harrased.

> This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-11-20 [https://issuetracker.google.com/issues/436510153]

Sounds like a threat to me. ffmpeg is a tiny team and Google is a goliath. Not to mention Google has used their AI to spam the same threat, about 8 times in the last few months https://ffmpeg.org/security.html

Re: FFmpeg dealing with a security researcher

#153

Post by eipi10_hn »

bawolff wrote: post #143
eipi10_hn wrote: post #124

Earlier quoted context omitted.

Duh no, wtf. No one has the duty to fix the security issue unless they are paid for the open source codes they give. They don't threaten you to use their codes either. If you want the security issue to be fixed, make a PR or offer the price you are willing to pay for them to fix.

By the same token nobody has the duty to responsibly disclose security bugs. The entire premise of responsible disclosure is that security researchers give time for upstream projects to fix security issues by privately reporting the issues, in exchange the maintainers graciously accept the reports. Its a deal that benefits maintainers much more than it benefits researchers. If ffmpeg doesn't want that deal, then goog…

Yes, that's right. Nobody has the duty to disclosure the security bugs. It's the security researchers' principles, and if they want to follow that, they can follow that.

But don't take it further that the maintainers have the duty to fix the issues. They choose that career, don't make it sound like ffmpeg is forcing them to disclosure. Maintainers don't "deal" with any security researchers about those, and don't put the confidence that it "benefits maintainers" than "benefit researchers", unless the maintainers declare that themselves. In this case there's no patch, no fix, no PR either, just issue-submission. "You have more benefits" are the claims of the researchers who think that their issue-submission contributions top everything else.

Finding and disclosing the security are issue-submission contributions, and that's it. Don't make it as a gift or something. ffmpeg doesn't have the need to find these issues, and they don't pay for it for it either. And vice versa, they have no duties to fix the issues. They don't force the security researchers to find and disclose things. If security researchers want to do it themselves, they can do whatever they want, but stop at forcing duties to the maintainers. The only thing I don't agree with ffmpeg is bringing those issues social while they can just ignore them, that's it.

Re: FFmpeg dealing with a security researcher

#154

Post by eviks »

haskellshill wrote: post #98
x0x0 wrote: post #82

Earlier quoted context omitted.

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?

There is no law you can't complain about lack of help on Twitter

Also, could you quote the request to sweep bugs under the rug?

The main ask seems to be "send patches" later in the thread

Re: FFmpeg dealing with a security researcher

#155

Post by astrange »

hulitu wrote: post #116
ls612 wrote: post #13

Earlier quoted context omitted.

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.

> despite the fact that approximately nobody was legitimately using JBIG2 in iMessage. Then why it has been enabled ? Asking for a friend. /s Unless Apple, ffmpeg has a reason to enable old codecs. If you only need a subset: configure; make; make install

> Then why it has been enabled ? Asking for a friend. /s

Because it's in the PDF spec, and you can't randomly disable parts of that.

Re: FFmpeg dealing with a security researcher

#156

Post by astrange »

yegle wrote: post #72
tkfoss wrote: post #26

Earlier quoted context omitted.

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

If you're using ffmpeg it's recommended to just enable the things you need, or only accept some container formats. But yes, in a generic package everything is enabled.

Re: FFmpeg dealing with a security researcher

#157

Post by Rebelgecko »

defrost wrote: post #105
haskellshill wrote: post #101

Earlier quoted context omitted.

Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?

> Right, they probably already mitigated this bug in their own usage. Indeed. A step so obvious it renders comments such as this: 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 moot. > Which is exactly why reporting the bug is a FAVOR to ffmpeg. Not sure you have to SHOUT the obvious. > Would you rather they just quietly fix it on their own and…

There's this weird "damned if you do, damned if you don't" situation on social media where people try to help and get reamed for not doing enough. Taylor Swift donated $500k to charity and people complaining she didn't round up to a million. After all, she can afford it.

But she ends up getting more criticism than the billionaire who donates nothing. Seems unfair but I guess it's human nature.

Re: FFmpeg dealing with a security researcher

#158

Post by Rebelgecko »

Klonoar wrote: post #83
haskellshill wrote: post #49

Earlier quoted context omitted.

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.

What expectation? Giving someone a heads up about a bug isn't a demand to fix it

Re: FFmpeg dealing with a security researcher

#159

Post by mappu »

hitekker wrote: post #80
mappu wrote: post #16

Kostya (ex-FFmpeg developer)'s take on the behaviour of the FFmpeg twitter account: https://codecs.multimedia.cx/2025/11/ffpropaganda/

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.

This isn't my place to argue, and certainly he was involved at the time, but LibAV wasn't really "his fork". Reading the full list of names who signed off https://lwn.net/Articles/423703/ I'm more interested in some other names, including darkshikari's deadname and the other heavy hitters of x264.

And if you browse through the ffmpeg mailing list of that historic month https://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/ you'll find his name mostly attached to esoteric video game format patches and not in the big flamewar threads.

Actually - it looks like you can also see in that same month, his post of the first SMUSH codec implementation, that we're discussing in this thread. That's probably a bigger emotional factor than LibAV.

Re: FFmpeg dealing with a security researcher

#160

Post by bawolff »

hitekker wrote: post #152
bawolff wrote: post #136

Earlier quoted context omitted.

Getting a polite bug report is not being harrased.

> This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2025-11-20 [ https://issuetracker.google.com/issues/436510153 ] Sounds like a threat to me. ffmpeg is a tiny…

Google is hardly the first people to come up with the notion of responsible disclosure. Whether you agree or not with the practise, the goal is to balance the needs of the maintainer with the needs of consumers. In practise such practises have massively boosted security of computer systems.

There is a lot of historical context with this sort of thing that has lead to systems like this that has nothing to do with google.

Besides google did not sign an NDA, they aren't under any obligation to keep anything secret. 90 days is a courtesy. They are fully within their rights to just publish their findings immediately if they felt like it.

Post reply on HN