7 ms·

The comments from the public.. Just wow we are doomed.. To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files

The comments from the public.. Just wow we are doomed.. To explain, Googles vulnerability scanner found a problem in an obscure decoder for a 1990s game files (Lucasfilm Smush). Devs are not happy they get timewasting reports on stuff that rarely anyone ever uses except an exceptionally tiny group. Then people start berating them without even knowing the full story...

cebert 11mo ago
I could see a compromise where if there are obscure codecs that may not be as secure, FFmpeg would present a warning before loading the file. This way, the user would have the option to decide whether to load the file or not. By default, potentially malicious files would not be loaded, which could prevent them from being used as part of an exploit. This seems like a reasonable compromise.
- kvemkon 11mo ago
  > FFmpeg would present a warning Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.
lukeschlather 11mo ago
Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.
- vreg 11mo ago
  If that is true then Google should be strictly sandboxing ffmpeg and filtering the input before it even gets there. A solid defense-in-depth approach would make sure it's highly unlikely this vulnerable code would be reached, and if it was, there would be effectively no impact. They should be building ffmpeg with a minimal feature set anyway, so none of these obscure codecs end up included in the final binary.
- tkfoss 11mo ago
  Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?
  - yegle 11mo ago
    Please stop spreading this misinformation. At least in Debian this is enabled by default (and as another post indicates, Ubuntu as well). Run the following command to confirm: ffmpeg -codecs|grep sanm
    - astrange 11mo ago
      If you're using ffmpeg it's recommended to just enable the things you need, or only accept some container formats. But yes, in a generic package everything is enabled.
    - tkfoss 11mo ago
      You re right, thanks! ffmpeg version 8.0 Copyright (c) 2000-2025 the FFmpeg developers ... D.V.L. sanm LucasArts SANM/SMUSH video
- chris_wot 11mo ago
  Then they can certainly afford to supply patches.
haskellshill 11mo ago
>rarely anyone ever uses It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4
- defrost 11mo ago
  If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs. In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.
  - Ukv 11mo ago
    To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).
    - GaryBluto 11mo ago
      Yeah but who cares about them, right? It's a volunteer project don't you know.
  - haskellshill 11mo ago
    Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?
    - defrost 11mo ago
      > Right, they probably already mitigated this bug in their own usage. Indeed. A step so obvious it renders comments such as this: It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4 moot. > Which is exactly why reporting the bug is a FAVOR to ffmpeg. Not sure you have to SHOUT the obvious. > Would you rather they just quietly fix it on their own and not report it to the maintainers? What do you suppose the answer to that question to be?

cebert 11mo ago

I could see a compromise where if there are obscure codecs that may not be as secure, FFmpeg would present a warning before loading the file. This way, the user would have the option to decide whether to load the file or not. By default, potentially malicious files would not be loaded, which could prevent them from being used as part of an exploit. This seems like a reasonable compromise.

kvemkon 11mo ago
> FFmpeg would present a warning Reminds me of gstreamer plugins being separated in "base", "good", "bad" and "ugly" sets.

lukeschlather 11mo ago

Google operates a transcoder API which I suspect is just ffmpeg under the hood, and if you assume that they accept any input file, they really can't afford for decoders to have security vulnerabilities. Of course, then Google should be coming with more resources and not just filing bugs because it's Google that has the unusual use case.

vreg 11mo ago
If that is true then Google should be strictly sandboxing ffmpeg and filtering the input before it even gets there. A solid defense-in-depth approach would make sure it's highly unlikely this vulnerable code would be reached, and if it was, there would be effectively no impact. They should be building ffmpeg with a minimal feature set anyway, so none of these obscure codecs end up included in the final binary.
tkfoss 11mo ago
Those decoders aren't even compiled and activated in the released binaries. But in any case, why would that be FFMPEGs problem?
- yegle 11mo ago
  Please stop spreading this misinformation. At least in Debian this is enabled by default (and as another post indicates, Ubuntu as well). Run the following command to confirm: ffmpeg -codecs|grep sanm
  - astrange 11mo ago
    If you're using ffmpeg it's recommended to just enable the things you need, or only accept some container formats. But yes, in a generic package everything is enabled.
  - tkfoss 11mo ago
    You re right, thanks! ffmpeg version 8.0 Copyright (c) 2000-2025 the FFmpeg developers ... D.V.L. sanm LucasArts SANM/SMUSH video
chris_wot 11mo ago
Then they can certainly afford to supply patches.

haskellshill 11mo ago

>rarely anyone ever uses It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

defrost 11mo ago
If only Google had the ability to custom compile FFmpeg to only include robust mainstream codecs. In such a would they might even handball submitted obscure codecs to a full build in a sandbox to track bleeding edge malware.
- Ukv 11mo ago
  To my understanding this bug would affect anyone using ffmpeg on untrusted input. Google may already be limiting to certain codecs in their own use, but should still report the issue (as they have here).
  - GaryBluto 11mo ago
    Yeah but who cares about them, right? It's a volunteer project don't you know.
- haskellshill 11mo ago
  Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?
  - defrost 11mo ago
    > Right, they probably already mitigated this bug in their own usage. Indeed. A step so obvious it renders comments such as this: It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4 moot. > Which is exactly why reporting the bug is a FAVOR to ffmpeg. Not sure you have to SHOUT the obvious. > Would you rather they just quietly fix it on their own and not report it to the maintainers? What do you suppose the answer to that question to be?