[AbrahamParangi]

If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.

[woodruffw]

I don’t think vulnerability researchers are having trouble finding exploitable bugs in FFmpeg, so I don’t know how much this actually holds. Much of the cost center of vulnerability research is weaponization and making an exploit reliable against a specific set of targets.

(The argument also seems backwards to me: Google appears to use a lot of not-inexpensive human talent to produce high quality reports to projects, instead of dumping an ASan log and calling it a day. If all they cared about was shoveling labor onto OSS maintainers, they could make things a lot easier for themselves than they currently do!)

[gcr]

Internally, Google maintains their own completely separate FFMpeg fork as well as a hardened sandbox for running that fork. Since they keep pace with releases to receive security fixes, there’s potentially lots of upstreamable work (with some effort on both sides…)

[eddd-ddde]

So your claim is that buggy software is better than documented buggy software?

[rsanek]

I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

[user3939382]

it’s not a claim it’s common sense that’s why we have notice periods

[gr4vityWall]

> it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg

At least, if this information is public, someone can act on it and sandbox ffmpeg for their use case, if they think it's worth it.

I personally prefer to have this information be accessible to all users.

[Aurornis]

This is a weird argument. Basically condoning security through obscurity: If nobody reports the bug then we just pretend it doesn’t exist, right?

There are many groups searching for security vulnerabilities in popular open source software who deliberately do not disclose them. They do this to save them for their own use or even to sell them to bad actors.

It’s starting to feel silly to demonize Google for doing security research at this point.

[KingMob]

> It’s starting to feel silly to demonize Google for doing security research at this point.

Aren't most people here demonizing Google for dedicating the resources to find bugs, but not to fix them?

[janalsncm]

I guess the question that a person at Google who discovers a bug they don’t personally have time to fix is, should they report the bug at all? They don’t necessarily know if someone else will be able to pick it up. So the current “always report” rule makes sense since you don’t have to figure out if someone can fix it.

The same question applies if they have time to fix it in six months, since that presumably still gives attackers a large window of time.

In this case the bug was so obscure it’s kind of silly.

[kragen]

It doesn't matter how obscure it is if it's a vulnerability that's enabled in default builds.

[rocqua]

This was not a case of stumbling across a bug. This was dedicated security research taking days if not weeks of high paid employees to find.

And after all that, they just drop an issue, instead of spending a little extra time on producing a patch.

[xign]

Except users can act accordingly to work around the vulnerability.

For one, it lets people understand where ffmpeg is at so they can treat it more carefully (e.g. run it in a sandbox).

Ffmpeg is also open source. After public disclosure, distros can choose to turn off said codec downstream to not expose this attack vector. There are a lot of things users can do to protect themselves but they need to be aware of the problem first.

[raincole]

Security by obscurity. In 2025. On HN.