Hacker News new | ask | show | jobs
by bawolff 235 days ago
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, they are just bitter that they have to fix bugs in their own code??? Recieving vuln reports is a gift. If ffmpeg doesnt like it maybe google should just start practising full disclosure.

2 comments

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.

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 does it need to be fixed?

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

This particular issue has a PoC to reproduce it. It seems very much that it would have real world impact
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?
Because it burns out developers and ruins the project. Its like how the treatment can be worse than the disease in medicine.

The CVEs get reported, then big corps automated systems start flagging all use of ffmpeg, the big corp security software stops builds and removes it from dev laptops, then frustrated big corp engineers start harassing the volunteers and soon its not worth volunteering anymore, and the project dies, and there was never a real world impact.

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 in a codec that most people will never use. If the trillion-dollar companies sending AI-generated CVE reports care so strongly about getting them fixed ASAP, they should really be fixing them themselves.
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.

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

> Recieving vuln reports is a gift.

A real gift would be to include a patch for it. Not just to run off into the sunset.