Earlier quoted context omitted.
Getting a polite bug report is not being harrased.
Fix it or we publish exploit code is not far off.
So let them publish exploit code. What's the problem?
FFmpeg dealing with a security researcher
141–150 of 174 posts
Re: FFmpeg dealing with a security researcher
#142Earlier quoted context omitted.
>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…
> because they use FFmpeg in a bunch of commercial products like Youtube and Chrome Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money. I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of * your code* .
> Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.
Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.
Re: FFmpeg dealing with a security researcher
#143Earlier quoted context omitted.
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.
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 google should go the full disclosure route.
> If you want the security issue to be fixed,
There is no indication that google actually cared much whether the issue got fixed or not. It seems like the course of events is that they noticed something looked wrong with the code so they filed a bug. That's it.
> willing to pay for them to fix.
Should ffmpeg pay for security researchers time to find these issues? The market price for that is much much much higher than the price to fix bugs.
If you were to pay someone to do vulnerability testing in ffmpeg with sufficient skill to find this issue, it would probably cost you in the hundreds of thousands of dollars at least.
Re: FFmpeg dealing with a security researcher
#144Earlier quoted context omitted.
Getting a polite bug report is not being harrased.
Fix it or we publish exploit code is not far off.
Well either you care about security or you don't.
If you don't then your users should have the right know, so they can decide for themselves whether or not the risk is worth it.
Do you think that just because a project doesn't disclose something it goes away, or that if google can find the bug that much better funded groups like the NSA or malware vendors can't. Shoving things under the rug is the worst outcome.
Re: FFmpeg dealing with a security researcher
#145[deleted]
Re: FFmpeg dealing with a security researcher
#146"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.
YouTube made $36.7 billion last year. Time they started pulling their weight.
They have around at least 3000 commits, assuming this search is right?
https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+%40google...
And they have done large pushes in the past: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
Re: FFmpeg dealing with a security researcher
#147Earlier quoted context omitted.
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…
I'd still consider that an academic exercise rather than an exploit that was deployed in the real world (aka against a machine the attacker did not control)
Yeah, that’s just how life is. We used to run with Heartbleed and Spectre turned off.
Re: FFmpeg dealing with a security researcher
#148Earlier quoted context omitted.
Chrome uses ffmpeg's underlying libraries. It's used way, way more than you think.
Yes, I’m quite familiar with that. Chrome is why I added the “generally” qualifier. And to the best of my knowledge, there has not been any in-the-wild exploit against Chrome through the handful of ffmpeg codecs they enable. Not even pwn2own type competitions either, as I recall.
I guess I'm confused - are you trying to imply the lack of a thorough, publicly reported successful exploit (or us just not casually giving you one that you care about) means that we're all released from the responsibility of taking potential exploits seriously?
Re: FFmpeg dealing with a security researcher
#149Earlier quoted context omitted.
Yeah but most public trackers will give lots of side eye to torrents that contain an mkv that isn’t in one of those two formats.
Really ? You think trackers download files and analyse their contents before listing them? I don't.
TPB? No. But 1337 and rutracker definitely do basic quality control. Nothing like a private tracker but they take down things like .mkv.lnk and similar.
Re: FFmpeg dealing with a security researcher
#150Earlier quoted context omitted.
Fix it or we publish exploit code is not far off.
Well either you care about security or you don't. If you don't then your users should have the right know, so they can decide for themselves whether or not the risk is worth it. Do you think that just because a project doesn't disclose something it goes away, or that if google can find the bug that much better funded groups like the NSA or malware vendors can't. Shoving things under the rug is the worst outcome.
What absolute nonsense. There's a gulf of difference between "there's no way 500+ codecs contributed mostly by unpaid hobbyists is robust to hostile input" and "here's working exploit code."