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

91–100 of 174 posts

Re: FFmpeg dealing with a security researcher

#91

Post by IshKebab »

ls612 wrote: post #65
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…

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.

But you don't need to use a popular codec, because all codecs are enabled by default.

Re: FFmpeg dealing with a security researcher

#94

Post by tjpnz »

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.

YouTube made $36.7 billion last year. Time they started pulling their weight.

Re: FFmpeg dealing with a security researcher

#95

Post by ozgrakkurt »

chemotaxis wrote: post #10
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.

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?

Re: FFmpeg dealing with a security researcher

#97

Post by haskellshill »

tehbeard wrote: post #88
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.

[flagged]

Re: FFmpeg dealing with a security researcher

#98

Post by haskellshill »

x0x0 wrote: post #82
hitekker wrote: post #76

Earlier quoted context omitted.

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.

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?

Re: FFmpeg dealing with a security researcher

#99

Post by haskellshill »

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.

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?

Re: FFmpeg dealing with a security researcher

#100

Post by haskellshill »

hdgvhicv wrote: post #89
haskellshill wrote: post #42

Earlier quoted context omitted.

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.

> you have 90 days to fix it

Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here.

If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.

Post reply on HN