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

101–110 of 174 posts

Re: FFmpeg dealing with a security researcher

#101

Post by haskellshill »

defrost wrote: post #53
haskellshill wrote: post #47

Earlier quoted context omitted.

>rarely anyone ever uses It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

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?

Re: FFmpeg dealing with a security researcher

#102

Post by anon_oss »

jsnell wrote: post #64
anon_oss wrote: post #6

[flagged]

So, this is the report they complained about: https://issuetracker.google.com/issues/440183164 I don't know how a vulnerability report could be much better than that. It is a real vulnerability. The report includes a detailed analysis of where the vulnerability is. The bug has been validated, and the report includes exact reproduction instructions. How is that a bullshit bug report?

Fair enough, I hadn't seen the bug report and assumed it was the usual AI slop.

Re: FFmpeg dealing with a security researcher

#103

Post by toofy »

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.

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

Re: FFmpeg dealing with a security researcher

#104

Post by anon_oss »

socalgal2 wrote: post #48
anon_oss wrote: post #6

[flagged]

Because not disclosing an actual bug that could affect users would somehow be good?

Sorry, I just needed to vent. I see now that Google's AI bug report isn't as bad as I'd assumed.

They should have included a patch though and they should have contacted ffmpeg team first before spamming them with dozens of issues all at once.

Re: FFmpeg dealing with a security researcher

#105

Post by defrost »

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?

> Right, they probably already mitigated this bug in their own usage.

Indeed. A step so obvious it renders comments such as this:

  It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4
moot.

> Which is exactly why reporting the bug is a FAVOR to ffmpeg.

Not sure you have to SHOUT the obvious.

> Would you rather they just quietly fix it on their own and not report it to the maintainers?

What do you suppose the answer to that question to be?

Re: FFmpeg dealing with a security researcher

#106

Post by awakeasleep »

haskellshill wrote: post #98
x0x0 wrote: post #82

Earlier quoted context omitted.

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.

Re: FFmpeg dealing with a security researcher

#107

Post by awakeasleep »

ozgrakkurt wrote: post #95
chemotaxis wrote: post #10

Earlier quoted context omitted.

The somewhat depressing reality is that if you're running ffmpeg on user-supplied multimedia without putting it in a bulletproof sandbox, you're just bound to have a bad time. Video decoding is one of these things that no one seems to know how to do safely in C or C++, not in the long haul. And that's probably fine, because we have lightweight sandboxing tech that makes this largely moot - but there's an extra step y…

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

In production? With a user-supplied film?

You seem to be captured by the “all or nothing” security fallacy, when security must be viewed through the lens of (probability) x (impact)

Re: FFmpeg dealing with a security researcher

#108

Post by [deleted] »

godelski wrote: post #77
haskellshill wrote: post #41

Earlier quoted context omitted.

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

> VLC is pretty popular on windows, but ffmpeg? I'm pretty confident VLC uses libavcodec > Is there any commonly used windows app that relies on it? A lot of stuff uses libavcodec

[deleted]

Re: FFmpeg dealing with a security researcher

#109

Post by Sophira »

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

Yes, lots. To name an example, yt-dip uses it on all platforms, including Windows, which means that any video downloader front-end that uses it also uses FFmpeg.

Re: FFmpeg dealing with a security researcher

#110

Post by ndiddy »

awakeasleep wrote: post #106
haskellshill wrote: post #98

Earlier quoted context omitted.

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 d…

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.
Post reply on HN