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

111–120 of 174 posts

Re: FFmpeg dealing with a security researcher

#111

Post by yeasku »

haskellshill wrote: post #99
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.

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

ffmpeg is getting DDOS'd by AI generated security CVEs.

Not by classic bug reports.

Re: FFmpeg dealing with a security researcher

#112

Post by estimator7292 »

ndiddy wrote: post #110
awakeasleep wrote: post #106

Earlier quoted context omitted.

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…

You're completely missing the point.

The problem isn't that volunteer devs are harassed into work.

The problem is being harassed.

Whether or not you "care" or feel the need to do any work or accept responsibility, constant harassment will destroy anyone, even you.

Re: FFmpeg dealing with a security researcher

#113

Post by brigade »

dpe82 wrote: post #84
brigade wrote: post #79

Earlier quoted context omitted.

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.

Yes, I know that multimedia/image vulnerabilities are popular vectors for zero-click attacks. My point is that desktop players are not a vector for zero-click attacks, and ffmpeg has not generally been used in end-user situations that are targets of zero-click or drive-by attacks. Mostly because of the license, but still.

If the exploit chain involves the user downloading and opening a file, something like >99% of the time the next step already involves executable code (or Office macros), which makes any ffmpeg vuln completely useless.

Re: FFmpeg dealing with a security researcher

#114

Post by polski-g »

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.

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.

Re: FFmpeg dealing with a security researcher

#115

Post by ls612 »

IshKebab wrote: post #91
ls612 wrote: post #65

Earlier quoted context omitted.

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.

Yeah but most public trackers will give lots of side eye to torrents that contain an mkv that isn’t in one of those two formats.

Re: FFmpeg dealing with a security researcher

#116

Post by hulitu »

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.

> 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

Re: FFmpeg dealing with a security researcher

#117

Post by brigade »

dns_snek wrote: post #90
brigade wrote: post #79

Earlier quoted context omitted.

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…

I'd still consider that an academic exercise rather than an exploit that was deployed in the real world (aka against a machine the attacker did not control)

Re: FFmpeg dealing with a security researcher

#118

Post by hulitu »

IshKebab wrote: post #27
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.

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…

> 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

Re: FFmpeg dealing with a security researcher

#119

Post by hulitu »

dns_snek wrote: post #90
brigade wrote: post #79

Earlier quoted context omitted.

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…

> Does this count?

If Signal relies on ffmpeg to play videos instead of an externall app, i would say it is broken by design.

Re: FFmpeg dealing with a security researcher

#120

Post by [deleted] »

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.

[deleted]
Post reply on HN