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

81–90 of 174 posts

Re: FFmpeg dealing with a security researcher

#81

Post by [deleted] »

ls612 wrote: post #13
vqtska wrote: post #7

I wonder if this vulnerable codec is enabled by default when building FFmpeg? Because if so, then it doesn't matter that it's a "1990s game codec" because any application using FFmpeg to accept arbitrary video files is vulnerable to memory corruption, which should probably be taken more seriously.

It isn't even like this is without precedent, the FORCEDENTRY NSO kit used the shitty old JBIG2 parser that Apple was shipping as its entry point despite the fact that approximately nobody was legitimately using JBIG2 in iMessage.

[deleted]

Re: FFmpeg dealing with a security researcher

#82

Post by x0x0 »

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.

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.

Re: FFmpeg dealing with a security researcher

#83

Post by Klonoar »

haskellshill wrote: post #49
Klonoar wrote: post #29

Earlier quoted context omitted.

I feel like you’re misunderstanding their point. It’s not that the vulnerability was found and reported , it’s that a trillion plus dollar organization that no doubt actively uses ffmpeg in a litany of spaces is punting the important work of fixing it to volunteers. This is the same issue that we’re seeing over with XSLT in Chrome: they’re happy when they’re making money off the back of these projects but balk when i…

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.

> If you don't want people to use your software to make money, release it with a license that prohibits that.

Or, y'know, the project could balk at a trillion dollar company expecting them to do free work.

Cuts both ways.

Re: FFmpeg dealing with a security researcher

#84

Post by dpe82 »

brigade wrote: post #79
dpe82 wrote: post #73

Earlier quoted context omitted.

VLC and ffmpeg share the same underlying library family (libav*) where this vulnerability lives. > I doubt it'd be worth one's time to write exploits for desktop Linux How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.

FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?

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.

Re: FFmpeg dealing with a security researcher

#85

Post by [deleted] »

IshKebab wrote: post #28
plorkyeran wrote: post #24

Earlier quoted context omitted.

No, all the ancient video game codecs and other such things that are there for historical preservation purposes but are rarely actually used are disabled by default and you have to really go out of your way to enable them. This was originally for binary size/build time reasons.

Are you sure? I ran `ffmpeg -codecs` on Ubuntu and it lists D.V.L. sanm LucasArts SANM/SMUSH video

[deleted]

Re: FFmpeg dealing with a security researcher

#86

Post by leoedin »

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.

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

Re: FFmpeg dealing with a security researcher

#87

Post by heavyset_go »

haskellshill wrote: post #41
IshKebab wrote: post #27

Earlier quoted context omitted.

I checked with Ubuntu's ffmpeg and it is enabled by default. There are a huge list of codecs enabled by default (maybe all of them?). 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. I think the same is probably true for VLC to a lesser extent, which is pretty wild considering I've never heard of it being used…

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

ffmpeg is deployed everywhere, and old versions of ffmpeg are baked into a lot of devices.

If you have a device that does image, audio or video, libav and/or ffmpeg is likely somewhere in the stack. Your TV, camera, console or streaming device might use the software.

If you're using SaaS that does image, audio or video, they are likely using ffmpeg related software somewhere in their stack.

Same thing with apps, Android and iOS apps might use the libraries, as well as desktop apps.

Re: FFmpeg dealing with a security researcher

#88

Post by tehbeard »

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…

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

Re: FFmpeg dealing with a security researcher

#89

Post by hdgvhicv »

haskellshill wrote: post #42
joatmon-snoo wrote: post #35

Earlier quoted context omitted.

No, this is the unfortunate reality of “ffmpeg is maintained by volunteers” and “CVE discovered on specific untrusted input”. Google’s AI system is no different than the oss-fuzz project of yesteryear: it ensures that the underlying bug is concretely reproducible before filing the bug. The 90-day disclosure window is standard disclosure policy and applies equally to hobby projects and Google Chrome.

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?

“This is broken, here’s how I fixed it”

Vs “this is broken, you gave 90 days to fix it”

If you can’t see the difference you’re the existential threat to Free software that stems from the trillion dollar industries that just take.

Re: FFmpeg dealing with a security researcher

#90

Post by dns_snek »

brigade wrote: post #79
dpe82 wrote: post #73

Earlier quoted context omitted.

VLC and ffmpeg share the same underlying library family (libav*) where this vulnerability lives. > I doubt it'd be worth one's time to write exploits for desktop Linux How many developers, network administrators, etc. run desktop Linux? Gaining access to those can be very, very valuable.

FFmpeg based players have been popular for 20 years now. Has there been a single documented actual use of their libraries as the exploitation vector anytime in the last two decades?

Does this count?

https://signal.org/blog/cellebrite-vulnerabilities/

> Given the number of opportunities present, we found that it’s possible to execute arbitrary code on a Cellebrite machine simply by including a specially formatted but otherwise innocuous file in any app on a device that is subsequently plugged into Cellebrite and scanned. There are virtually no limits on the code that can be executed.

But it was a product using a 9 year old ffmpeg build (at the time).

Post reply on HN