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

31–40 of 174 posts

Re: FFmpeg dealing with a security researcher

#31

Post by gnfargbl »

FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1].

On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain.

On the other hand, we have plenty of evidence that untrusted input validation bugs pose a very high risk to end users. So, for as long as this is their policy, FFmpeg code really should not be included in any system where security is at all important. Perhaps we need a "fundamentally unsafe for use" sticker for OSS projects taking this stance?

[1] https://x.com/FFmpeg/status/1984425167070630289

Re: FFmpeg dealing with a security researcher

#32

Post by vreg »

gnfargbl wrote: post #31

FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1]. On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain. On the other hand, we have plenty of evidence that untrusted input validation bugs pose a ver…

All code should be considered potentially vulnerable, that's why we have so many layers of exploit mitigation from the compiler to the runtime environment to the overall design of the system the code is running in.

Re: FFmpeg dealing with a security researcher

#33

Post by TZubiri »

gnfargbl wrote: post #31

FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1]. On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain. On the other hand, we have plenty of evidence that untrusted input validation bugs pose a ver…

> unless you pay them

You can't pay for the software

>"FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment"

https://www.ffmpeg.org/legal.html

Re: FFmpeg dealing with a security researcher

#34

Post by TZubiri »

cebert wrote: post #2

It looks like the FFmpeg account on X is calling out Google for using AI to mass-report CVEs in obscure volunteer maintained codecs, then expecting unpaid maintainers to rush fixes. Large, profitable firms rely on FFmpeg everywhere, but don’t seem to be contributing much to the project.

You think google uses ffmpeg for youtube?

Re: FFmpeg dealing with a security researcher

#35

Post by joatmon-snoo »

cebert wrote: post #2

It looks like the FFmpeg account on X is calling out Google for using AI to mass-report CVEs in obscure volunteer maintained codecs, then expecting unpaid maintainers to rush fixes. Large, profitable firms rely on FFmpeg everywhere, but don’t seem to be contributing much to the project.

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.

Re: FFmpeg dealing with a security researcher

#36

Post by joatmon-snoo »

TZubiri wrote: post #34
cebert wrote: post #2

It looks like the FFmpeg account on X is calling out Google for using AI to mass-report CVEs in obscure volunteer maintained codecs, then expecting unpaid maintainers to rush fixes. Large, profitable firms rely on FFmpeg everywhere, but don’t seem to be contributing much to the project.

You think google uses ffmpeg for youtube?

They do.

Re: FFmpeg dealing with a security researcher

#37

Post by [deleted] »

TZubiri wrote: post #33
gnfargbl wrote: post #31

FFmpeg seem to be taking the position that their code must be considered insecure in production unless you pay them for security consulting [1]. On the one hand, that's fine; it's their project, and if attack surface is not a priority for them, or they want to monetise that function, then nobody else has a right to complain. On the other hand, we have plenty of evidence that untrusted input validation bugs pose a ver…

> unless you pay them You can't pay for the software >"FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment" https://www.ffmpeg.org/legal.html

[deleted]

Re: FFmpeg dealing with a security researcher

#38

Post by TZubiri »

sillywabbit wrote: post #18
GaryBluto wrote: post #14

Earlier quoted context omitted.

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.

For a bug in the LucasArts Smush codec? Why didn't you verify it was an mp4/h264 first?

Mp4 is an envelope codec, so it could be both an mp4 and an obscure codec

Re: FFmpeg dealing with a security researcher

#39

Post by joatmon-snoo »

fabrice_d wrote: post #12
GaryBluto wrote: post #8

Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…

It is absolutely Google's security issue if they use an open source project with that license: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING.... and then expect volunteers to provide them fixes.

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.

Re: FFmpeg dealing with a security researcher

#40

Post by spongebobstoes »

vreg wrote: post #23
GaryBluto wrote: post #8

Rather unprofessional for an official project twitter account to complain about "slop" > We take security very seriously but at the same time is it really fair that trillion dollar corporations run AI to find security issues on people's hobby code? Then expect volunteers to fix. Yes. If a vulnerability exists, it's wise to report it. You don't need to fix it immediately (nobody has got a gun to your head) but just be…

This is a volunteer-run open source project. Your expectations are unrealistic and, to be quite frank, offensive.

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.

Post reply on HN