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

131–140 of 174 posts

Re: FFmpeg dealing with a security researcher

#131

Post by phil21 »

brigade wrote: post #113
dpe82 wrote: post #84

Earlier quoted context omitted.

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.

Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still. If the exploit chain involves the user downloading and opening a file, something like >99% of th…

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.

Re: FFmpeg dealing with a security researcher

#132

Post by brigade »

dpe82 wrote: post #126
brigade wrote: post #113

Earlier quoted context omitted.

Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still. If the exploit chain involves the user downloading and opening a file, something like >99% of th…

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.

Re: FFmpeg dealing with a security researcher

#133

Post by brigade »

phil21 wrote: post #131
brigade wrote: post #113

Earlier quoted context omitted.

Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still. If the exploit chain involves the user downloading and opening a file, something like >99% of th…

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.

Re: FFmpeg dealing with a security researcher

#134

Post by bawolff »

waste_monk wrote: post #78
bawolff wrote: post #71

Earlier 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.

>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…

Security vulnerability finding is a contribution. On the open market the type of service google is providing here would cost hundreds of thousands of dollars if not millions.

Re: FFmpeg dealing with a security researcher

#135

Post by bawolff »

hitekker wrote: post #76
bawolff wrote: post #70

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, t…

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.

This particular issue has a PoC to reproduce it. It seems very much that it would have real world impact

Re: FFmpeg dealing with a security researcher

#136

Post by bawolff »

estimator7292 wrote: post #112
ndiddy wrote: post #110

Earlier quoted context omitted.

My point of view is that the unpaid ffmpeg maintainers should stop playing along with the corporate "security researchers" and not prioritize a bug over everything else simply because it's a CVE. In this case, the "high priority CVE" is from a reverse-engineered codec a hobbyist wrote to decode video from 1990s LucasArts video games. I think it's unreasonable to expect the maintainers to drop everything to fix a bug…

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.

Re: FFmpeg dealing with a security researcher

#137

Post by bawolff »

leoedin wrote: post #86
bawolff wrote: post #71

Earlier 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.

> 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…

> 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?

Yes, i think there is a moral duty if you are presenting the software for the general public to use. Or if you dont to at least make it clear how you handle stuff so that users can make their own decisions.

> But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.

In your view would it be acceptable to backdoor open source software to sell user's data to the highest bidder? That's obviously not what happened here, but seems like the obvious conclusion of your argument.

Re: FFmpeg dealing with a security researcher

#138

Post by ronsor »

secondcoming wrote: post #60
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/

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.

Reverse engineering for interoperability is generally legal. Even if not, copyright does not follow the "fruit of the poisoned tree" idea, so if the new code isn't substantially similar to the original, it doesn't matter.

Re: FFmpeg dealing with a security researcher

#139

Post by IshKebab »

ls612 wrote: post #115
IshKebab wrote: post #91

Earlier quoted context omitted.

But you don't need to use a popular codec, because all codecs are enabled by default.

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.

Re: FFmpeg dealing with a security researcher

#140

Post by x0x0 »

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.

Fix it or we publish exploit code is not far off.
Post reply on HN