• 1 Post
  • 105 Comments
Joined 2 years ago
cake
Cake day: June 22nd, 2023

help-circle

  • I don’t understand how a bug is supposed to know whether it’s triggered inside or outside of a google service. If the bug can only be triggered in some weird, google-specific deployment, that’s one thing, but I don’t think that’s what we’re talking about here. If the bug is manifestly present in ffmpeg and it’s discovered at google, what are you saying is supposed to happen? Google should a) report it under the normal 90 day disclosure rule; b) report it but let it stay undisclosed for longer than normal, due to the resource contraints ffmpeg’s devs areunder; c) not report it and let some attacker exploit it? (b) might have some merit but (c) is insane. Once some bad actor finds out about the bug (through independent discovery or any other way), it’s going to be exploited. That might already be happening before even google finds the bug.

    FFmpeg’s codebase and dev community are both exceptionally difficult and that is not helping matters, I’m sure.

    There are a bunch of Rust zealots busily rewriting GNU Coreutils which in practice have been quite reliable and not that badly in need of rewriting. Maybe the zealots should turn their attention to ffmpeg (a bug minefield of long renown) instead.

    Alternatively (or in addition), some effort should go into sandboxing ffmpeg so its bugs can be contained.


  • AI reports are ignored because they are so frequently crap that they are almost not worth investigating. If these ffmpeg reports are from Project Zero though, they are presumably real. Shipping code with vulnerabilities is always a terrible idea. If Google can find them, attackers can also find them.

    I do have to wonder how many of these vulnerabilities are actually in the assembly language parts of the codecs. I had guessed they were more likely to be at the higher levels.