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

121–130 of 174 posts

Re: FFmpeg dealing with a security researcher

#121

Post by rurban »

yeasku wrote: post #111
haskellshill wrote: post #99

Earlier quoted context omitted.

What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug. > currently have zero real-world impact So better we not talk about them until someone bothers to write an exploit for it? > the "researchers" didn't even bother to write a patch/fix If it has no real-world impact and thus shouldn't even be reported, then why doe…

ffmpeg is getting DDOS'd by AI generated security CVEs. Not by classic bug reports.

It's a pretty good report by bigsleep. It even comes with a good explanation and reproducer.

I like to get such reports from the occasional fuzzer. Just ignore the CVE, it's a bug

Re: FFmpeg dealing with a security researcher

#122

Post by ndiddy »

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.

My hope is that if they started responding to CVE bug reports for hobby codecs with something like “This is a codec written by someone in his free time and intended to be used for preservation purposes. We do not support using this codec with untrusted input and may not implement a fix for this bug within the 90 day CVE timeline”, it would stop the harassment. The companies doing the CVE spam would either have to start fixing things themselves, contract someone to do so, or stop using ffmpeg due to all the scary CVEs getting flagged in whatever bullshit security compliance standard they use.

Re: FFmpeg dealing with a security researcher

#123

Post by blueg3 »

cebert wrote: post #2

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.

I don't think Google is expecting anything here.

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.

Re: FFmpeg dealing with a security researcher

#124

Post by eipi10_hn »

bawolff wrote: post #71
PaulKeeble wrote: post #4

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

Re: FFmpeg dealing with a security researcher

#125

Post by array_key_first »

haskellshill wrote: post #101
defrost wrote: post #53

Earlier quoted context omitted.

If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs. In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.

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?

I would rather they fix it and submit a patch like normal fucking people.

Re: FFmpeg dealing with a security researcher

#126

Post by dpe82 »

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…

Chrome uses ffmpeg's underlying libraries.

It's used way, way more than you think.

Re: FFmpeg dealing with a security researcher

#127

Post by godelski »

bawolff wrote: post #71
PaulKeeble wrote: post #4

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

Doesn't Chrome use libavcodec?

I'm somewhat with you but we're also talking about a $3.4T company that's depending on an OSS project with what... under a $1m budget? It seems they're pretty resource constrained.

I'm pretty sure Google makes more through Chrome's usage of libav than ffmpeg's entire budget. So yeah, I think Google should put effort back in and I think it's in their best interest.

Trillion dollar companies standing on top of open source projects and giving little to nothing back is not okay. It's also just stupid since they're eating their own foundations

Re: FFmpeg dealing with a security researcher

#128

Post by godelski »

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…

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

Re: FFmpeg dealing with a security researcher

#129

Post by x0x0 »

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…

Be careful, the Europeans tried (had the python foundation not pushed back hard, would have) and still would love to require anyone who's ever built a piece of software to perform maintenance for them on demand.

Re: FFmpeg dealing with a security researcher

#130

Post by phil21 »

ndiddy wrote: post #122
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.

My hope is that if they started responding to CVE bug reports for hobby codecs with something like “This is a codec written by someone in his free time and intended to be used for preservation purposes. We do not support using this codec with untrusted input and may not implement a fix for this bug within the 90 day CVE timeline”, it would stop the harassment. The companies doing the CVE spam would either have to sta…

It would not stop the harassment at all. These reports are effectively free for the originating organization to write using AI - and some low level junior looking for promotion within said org will be highly motivated to pump those metrics up come review time.

You’d have to basically blacklist these orgs from all bug reports and maybe open it up to a select few known trusted senior resources that care more about their personal reputation within the community vs. corporate politics.

Post reply on HN