5 ms·

> "Don't come to me with problems, come with solutions" The problem is, the issue in the article is explicitly named as "CVE slop", so if the patch is of the s

> "Don't come to me with problems, come with solutions" The problem is, the issue in the article is explicitly named as "CVE slop", so if the patch is of the same quality, it might require quite some work anyway.

jeffbee 11mo ago
The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1 https://issuetracker.google.com/issues/440183164?pli=1
- michaelt 11mo ago
  It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't been used since the Clinton administration. gstreamer divides their plugins into 'good', 'bad' and 'ugly' to give them somewhere to stash unmaintained codecs. [1] https://web.archive.org/web/20250419105551/https://wiki.multimedia.cx/index.php/SAN https://web.archive.org/web/20250419105551/https://wiki.mult...
  - jsnell 11mo ago
    It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as the common ones. > Pretty crazy that ffmpeg supports the codec in the first place, IMHO. Yes.
    - Wowfunhappy 11mo ago
      Ffmpeg makes it trivial to enable and disable individual codecs at compile time. Perhaps it's the Linux distros that need to make a change here?
      - dotancohen 11mo ago
        Every change breaks somebody's workflow.
        deleted 11mo ago
        [deleted]
      - tpmoney 11mo ago
        I get that the ffmpeg people have limited time and resources, I get that it would be nice if Google (or literally anyone else) patched this themselves and submitted that upstream. But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. If this is so obscure of a bug that there's no real risk, then there's no need for anyone to worry that the bug has been reported and will be publicized. On the other hand, if it's so dangerous that everyone should be rebuilding ffmpeg from source and compiling it out, then it really needs to be fixed in the up stream. Edit: And also, how is anyone supposed to know they should compile the codec our unless someone makes a bug report and makes it public in the first place?
        bigiain 11mo ago
        > But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. Is that somehow _less_ of a terrible way to think than "someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company"? > it really needs to be fixed in the up stream Lots of people love using "Free Software" that they didn't have to write as essential parts of their business. Way too many of them seem to blink right when they get to this bit of the licence they got it with: SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. (That's directly from Section 15 "NO WARRANTY of https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0/COPYING.LGPLv2.1 https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0... )
  - jeffbee 11mo ago
    Yeah but as you can see from the bug report ffmpeg automatically triggers the codec based on file magic, so it is possible that if you run some kind of network service or anything that handles hostile data an attacker could trigger the bug.
    - Jweb_Guru 11mo ago
      It feels like maybe people do not realize that Google is not the only company that can run fuzzers against ffmpeg? Attackers are also highly incentivized to do so and they will not do you the courtesy of filing bug reports.
  - emmelaich 11mo ago
    Best response would be to drop this codec entirely, or have it off by default. At least distros should do that.
    - Jweb_Guru 11mo ago
      The actual best response would be to run any "unsupported" codecs in a WASM sandbox. That way you are not throwing away work, Google can stop running fuzzers against random formats from 1995, and you can legitimately say that the worst that can happen with these formats is a process crash. Everybody wins.
  - rossjudson 11mo ago
    I'm sure that a hacker wouldn't think of trying to use an obscure format... https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
    - godelski 11mo ago
      > If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it. That's not an obscure format, that's an old format. Meanwhile with ffmpeg we're talking about > decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995. That's both old and obscure. Your point is still taken, but just to clarify that these are different situations. JBIG2 is included for legacy. The Lucas art codec is included for... completion's sake(?)
      - adgjlsfhk1 11mo ago
        The problem is that if you have a process using ffmpeg and an attacker feeds it a video with this codec, ffmpeg will proceed to auto-detect the codec, attempt to decrypt and then then break everything. If the format is old and obscure, and the implementation is broken, it shouldn't be on by default.
        godelski 11mo ago
        Sorry, I probably wasn't clear enough in my comment. I was trying to say that being old gives some legitimacy for existing. Just because it is old doesn't mean it isn't used. Though yes, this should be better determined to make sure it isn't breaking workflows you don't know about. But old AND obscure, well it's nice that it is supported but enabled by default? Fully with you there.
  - bigiain 11mo ago
    Hmmmm. There's probably just one guy who wrote the ffmpeg code for that format. _Maybe_ one or two more who contributed fixes or enhancements? The ffmpeg project need to get in touch and get then to assign copyright to the ffmpeg project, then delete that format/decoder from ffmpeg. Then go back to Google with an offer to licence then a commercial version of ffmpeg with the fixed SANM ANIM v0 decoder, for the low low price of only 0.0001% of YouTube's revenue every year. That'd likely make them the best funded open source project ever, if they pulled it off.

jeffbee 11mo ago

The linked report seems to me to be the furthest thing from "slop". It is an S-tier bug report that includes a complete narrative, crash artifacts, and detailed repro instructions. I can't believe anyone is complaining about what is tied for the best bug report I have ever seen. https://issuetracker.google.com/issues/440183164?pli=1 https://issuetracker.google.com/issues/440183164?pli=1

michaelt 11mo ago
It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't been used since the Clinton administration. gstreamer divides their plugins into 'good', 'bad' and 'ugly' to give them somewhere to stash unmaintained codecs. [1] https://web.archive.org/web/20250419105551/https://wiki.multimedia.cx/index.php/SAN https://web.archive.org/web/20250419105551/https://wiki.mult...
- jsnell 11mo ago
  It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as the common ones. > Pretty crazy that ffmpeg supports the codec in the first place, IMHO. Yes.
  - Wowfunhappy 11mo ago
    Ffmpeg makes it trivial to enable and disable individual codecs at compile time. Perhaps it's the Linux distros that need to make a change here?
    - dotancohen 11mo ago
      Every change breaks somebody's workflow.
      - deleted 11mo ago
        [deleted]
    - tpmoney 11mo ago
      I get that the ffmpeg people have limited time and resources, I get that it would be nice if Google (or literally anyone else) patched this themselves and submitted that upstream. But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. If this is so obscure of a bug that there's no real risk, then there's no need for anyone to worry that the bug has been reported and will be publicized. On the other hand, if it's so dangerous that everyone should be rebuilding ffmpeg from source and compiling it out, then it really needs to be fixed in the up stream. Edit: And also, how is anyone supposed to know they should compile the codec our unless someone makes a bug report and makes it public in the first place?
      - bigiain 11mo ago
        > But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. Is that somehow _less_ of a terrible way to think than "someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company"? > it really needs to be fixed in the up stream Lots of people love using "Free Software" that they didn't have to write as essential parts of their business. Way too many of them seem to blink right when they get to this bit of the licence they got it with: SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. (That's directly from Section 15 "NO WARRANTY of https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0/COPYING.LGPLv2.1 https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0... )
- jeffbee 11mo ago
  Yeah but as you can see from the bug report ffmpeg automatically triggers the codec based on file magic, so it is possible that if you run some kind of network service or anything that handles hostile data an attacker could trigger the bug.
  - Jweb_Guru 11mo ago
    It feels like maybe people do not realize that Google is not the only company that can run fuzzers against ffmpeg? Attackers are also highly incentivized to do so and they will not do you the courtesy of filing bug reports.
- emmelaich 11mo ago
  Best response would be to drop this codec entirely, or have it off by default. At least distros should do that.
  - Jweb_Guru 11mo ago
    The actual best response would be to run any "unsupported" codecs in a WASM sandbox. That way you are not throwing away work, Google can stop running fuzzers against random formats from 1995, and you can legitimately say that the worst that can happen with these formats is a process crash. Everybody wins.
- rossjudson 11mo ago
  I'm sure that a hacker wouldn't think of trying to use an obscure format... https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
  - godelski 11mo ago
    > If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it. That's not an obscure format, that's an old format. Meanwhile with ffmpeg we're talking about > decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995. That's both old and obscure. Your point is still taken, but just to clarify that these are different situations. JBIG2 is included for legacy. The Lucas art codec is included for... completion's sake(?)
    - adgjlsfhk1 11mo ago
      The problem is that if you have a process using ffmpeg and an attacker feeds it a video with this codec, ffmpeg will proceed to auto-detect the codec, attempt to decrypt and then then break everything. If the format is old and obscure, and the implementation is broken, it shouldn't be on by default.
      - godelski 11mo ago
        Sorry, I probably wasn't clear enough in my comment. I was trying to say that being old gives some legitimacy for existing. Just because it is old doesn't mean it isn't used. Though yes, this should be better determined to make sure it isn't breaking workflows you don't know about. But old AND obscure, well it's nice that it is supported but enabled by default? Fully with you there.
- bigiain 11mo ago
  Hmmmm. There's probably just one guy who wrote the ffmpeg code for that format. _Maybe_ one or two more who contributed fixes or enhancements? The ffmpeg project need to get in touch and get then to assign copyright to the ffmpeg project, then delete that format/decoder from ffmpeg. Then go back to Google with an offer to licence then a commercial version of ffmpeg with the fixed SANM ANIM v0 decoder, for the low low price of only 0.0001% of YouTube's revenue every year. That'd likely make them the best funded open source project ever, if they pulled it off.