←back to thread

FFmpeg dealing with a security researcher

(twitter.com)
104 points trollied | 3 comments | 01 Nov 25 20:59 UTC | HN request time: 0s | source
Show context
PaulKeeble ◴[01 Nov 25 21:46 UTC] No.45785696[source]▶
"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.
replies(4): >>45785935 #>>45786972 #>>45788047 #>>45789281 #
bawolff ◴[02 Nov 25 05:34 UTC] No.45788047[source]▶
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.

replies(9): >>45788126 #>>45788148 #>>45788195 #>>45788490 #>>45789829 #>>45791054 #>>45791689 #>>45792479 #>>45792591 #
waste_monk ◴[02 Nov 25 06:21 UTC] No.45788195[source]▶
>I think that is a little entitled. They should be happy google isn't just straight up emailing full-disclisure.

Google has literally billions of dollars in profits (in part because they use FFmpeg in a bunch of commercial products like Youtube and Chrome), and one of the largest software workforces in the world, including expertise on secure software and vulnerability remediation.

If anyone can afford to contribute back a fix instead of just raising a report, and has the ethical responsibility to do so, it's Google.

replies(2): >>45792609 #>>45793231 #
1. godelski ◴[02 Nov 25 19:09 UTC] No.45792609[source]▶

  > because they use FFmpeg in a bunch of commercial products like Youtube and Chrome
Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.

I'm not sure why this is an unpopular idea, but contribute back to your upstream dependencies. If they're a dependency, they're part of *your code*.

replies(1): >>45793815 #
2. bawolff ◴[02 Nov 25 22:01 UTC] No.45793815[source]▶
> Not to mention they just have a vested interest in getting the problem solved. Even if we don't talk about money.

Correct me if im wrong, but based on the report this looks like something that would affect regular users of ffmpeg but not google's use.

replies(1): >>45806230 #
3. godelski ◴[04 Nov 25 00:33 UTC] No.45806230[source]▶
FWIW I tried replicating it and didn't get the same result. I end up with a failed conversion, exit code 69[0]. Same thing when I run with my installed version of ffmpeg.

But I think Google would still be concerned. Even if they're running ffmpeg in a sandbox you can escape sandboxes. The sandbox is a security layer, not what makes the thing safe. You should be using it as a layer of defense for unknown vulns, and try to resolve vulns. I mean Google is much more likely to have an attacker trying to chain a vuln with a sandbox escape than the average user.

Btw:

  ffmpeg -codecs | cat | grep SANM 2&>/dev/null
  ffmpeg version n8.0 Copyright (c) 2000-2025 the FFmpeg developers
  ... ffmpeg flags ...
  D.V.L. sanm                 LucasArts SANM/SMUSH video
So my version does have that codec, as others are reporting.

[0] Will expire soon https://0x0.st/KL6K.log

[DISCLOSURE]: I AM NOT A SECURITY PROFESSIONAL. If I am wrong please correct me