Does this mean we have to run vlc in a sandbox while watching a downloaded film?

> despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.

Then why it has been enabled ? Asking for a friend. /s

Unless Apple, ffmpeg has a reason to enable old codecs. If you only need a subset: configure; make; make install

I think that the x264 and hevc codecs are much more battle tested and a 0day for them would be worth enough that nobody would bother using it on random torrenters.

> Given the security track record of codecs implemented in C, this means it's basically guaranteed that there are dozens of security vulnerabilities in ffmpeg.

Or in, you know, external libraries. Maybe ffmeg shall be run with sanitized input (and not from a "web page" ) ? Just saying

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists

   D.V.L. sanm                 LucasArts SANM/SMUSH video

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.

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?

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

>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 back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.

> 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 seen as negligent, violate regulations or the contract they have with their customers. But there’s no contract with the free software developers. No duty of care from them to end users. Absolutely no duty.

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

Nah, it's entitlement to expect maintainers to overwork and fix every single "security" issue thrown their way. ffmpeg has just a few resources and Google has way, way more. The maintainers are not your servants nor are they Google's servants.

It's a volunteer run project... Saying that they have a duty to do anything other than what they want is quite strange.

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.

i’m sorry, but when it comes to open source software if you want something on your timeline, you do it. the code is there. it’s _open_.

if “a duty” exists at all in this situation, it’s on the 4th wealthiest company in the world who is using that free software to serve its customers and raking in billions of dollars. (i want to be clear tho, that company does contribute a lot to the open source community. a whole lot. i’m just saying, if someone is hunting for a “duty” to fling around re: an open source project)

i was once naively saying some undeserved similar nonsense to a well known open source dev regarding some software package they were working on years ago, and he responded absolutely appropriately, [paraphrasing] “go ahead, you should absolutely do it, see if it’s better. none of us here are stopping you. we genuinely hope it is, truly. let us know. until then we’re working on other stuff.”

he was absolutely correct and i should have known better. not snotty at all, just, “you should totally do it!” that’s the appropriate answer every single time someone behaves as if your open source project owes them something. even more so when it’s the 4th richest company in the world.

so if you feel “a duty” exists somewhere to change something with ffmpeg, do it yourself. literally no one is stopping you. it’s _open source_.

No person, ever, has a duty to fix security issues in free software with a no-warranty license. If you want your security fixes, pay for them.

Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?

They did once upon a time atleast.[1] Most videos probably go through dedicated hardware nowadays, but it wouldn't surprise me if some videos still have to go the FFmpeg route that catches all the videos that the dedicated hardware can't handle.

[1] https://web.archive.org/web/20110315155125/https://multimedi...

They do.

> paid off handsomely

Paid off how? Did they get more funding? More contributors?

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.

I edited my post to make the nature of the requested payment clearer.

If that is true then Google should be strictly sandboxing ffmpeg and filtering the input before it even gets there. A solid defense-in-depth approach would make sure it's highly unlikely this vulnerable code would be reached, and if it was, there would be effectively no impact.

They should be building ffmpeg with a minimal feature set anyway, so none of these obscure codecs end up included in the final binary.

Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?

Then they can certainly afford to supply patches.

> FFmpeg would present a warning

Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.

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.

It would be nice if they helped fix it, and maybe they don't help enough in general?, but as ffmpeg says this specific codec is just a hobby project for ancient obscure files. **Google gains zero value from this codec.** Disabling it would be plenty to fix the problem on their end.

But that would leave everyone else vulnerable, so they report it. Reporting real problems is a good thing.

Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.

Google never asked a volunteer for a fix.

This is part of Google’s standard disclosure policy: it gets disclosed within 90 days starting from confirmation+contact.

If ffmpeg didn’t want to fix it, they could’ve just let the CVE get opened.

It's not just Google who could be affected by this.

> and then expect volunteers to provide them fixes.

Expect volunteers to provide everyone using the software with fixes.

What are their expectations, and which are unrealistic?

It reads to me like the only expectation is civility, not even necessarily an expectation of fixing it.

If Google can identify a vulnerability, what should they do? If they don't report it, they're effectively stockpiling weapons.

I'd wager that every usage of ffmpeg in Google infra is sandboxed, so calling this "Google's problem" seems silly to me.

Google can't be responsible for fixing everyone's sloppy C code.

If a volunteer-run project wants to be full of CVEs and inevitably bleed users because of it, fine, but to whine about someone reporting a CVE in the first place is ridiculous. I'm not annoyed they haven't fixed it, I'm annoyed they're complaining about the problem being acknowledged.