17 ms·

This is conflating two very different issues. While ffmpeg certainly has its share of vulnerabilities in part caused by it being an old and crusty C project, th

This is conflating two very different issues. While ffmpeg certainly has its share of vulnerabilities in part caused by it being an old and crusty C project, that has little to do with video glitches. Video glitches are usually caused by corner cases in decoding, e.g. issues with reference frames during seeking. Those are logic errors, which any project handling video formats would be prone to because video codecs are ridiculously complicated these days. Your blocky errors in video playback aren't caused by a pointer going wild due to bad pointer math in ffmpeg. They're caused by bad or corrupted input or an improper seek to a non IDR point in the file. ffmpeg is rock solid for playback of standard corruption-free h.264 streams. This idea that any time you see corrupted video it's a (potentially exploitable) bug in ffmpeg is just not true. Nobody is getting "signal drops" due to ffmpeg problems. Now if you start fuzzing ffmpeg and giving it wildly noncompliant and broken input, yes, you're going to run into memory errors at some point - which is why there are companies doing just that these days, to find and fix those security flaws. Most of those bugs aren't even in popular codecs (since those are extremely well tested), but rather in the very long tail of obscure formats that ffmpeg supports (try counting how many obscure video game formats it supports some time!), and therefore in codepaths that nobody watching YouTube or Twitch is ever going to hit.

ellis0n 5y ago
This is a code audit issue. Video codecs and drivers are a niche and are extremely protected by patents. The number of ffmpeg researchers and developers is very small compared to the number of lines of code, closed standards and soft/hard bugs in each series of specific video hw/sw encoders and decoders. And an AI that can analyze and validate code as complex as ffmpeg has yet to be invented.
- marcan_42 5y ago
  It's a programming language issue. Any time you're writing complex format parsing code in an unsafe language like C, you're going to run into these problems. Unfortunately, Rust didn't exist when ffmpeg was created. Patents have absolutely nothing to do with this; they don't affect the security of the resulting code. Nobody can write code for all the formats ffmpeg supports and do it safely, in C. Nobody. You think audits work? Tell that to Infineon, who shipped a broken RSA key generator implementation. In a cryptography product. Which was audited privately. And that's a critical part of the code that should've had many eyes on it. Perfect memory safety for C parsers for hundreds of formats? Yeah, not going to happen. It has nothing to do with the code quality of ffmpeg. It's just not humanly possible to get this right in every instance.
  - qayxc 5y ago
    > It's just not humanly possible to get this right in every instance. That's what theorem provers and model driven development are for. I wish these tools could be used more. There should also be automated completeness checkers for requirements and specs - a lot of errors, incompatibilities and security issues are the result of ambiguous, contradictory, or incomplete specs and requirements.
    - marcan_42 5y ago
      > That's what theorem provers and model driven development are for. That's building a safe programming language on top of an unsafe one. At that point you might as well just use a safe programming language. That won't fix logic errors, but the vast majority of security issues are safety problems, especially in this kind of codebase.
    - ellis0n 5y ago
      There is no algorithm in the world for how to check whether a video codec is working correctly or not
      - afiori 5y ago
        The model checking would not check the output but the trace of operations. It might prove that all bytes of the output were written to at least once, that dereferenced pointers point toward either the input or some other valid structure, and other properties like this.
  - ellis0n 5y ago
    I agree with RSA key generator implementation idea and I like Rust is better C idea
  - deleted 5y ago
    [deleted]
mikaraento 5y ago
ffmpeg/libav is being fuzzed with reasonable success. See for example https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg https://github.com/google/oss-fuzz/tree/master/projects/ffmp... and https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html https://security.googleblog.com/2014/01/ffmpeg-and-thousand-.... They found issues in code I wrote... (I work for Google but do not speak for it)

ellis0n 5y ago

This is a code audit issue. Video codecs and drivers are a niche and are extremely protected by patents. The number of ffmpeg researchers and developers is very small compared to the number of lines of code, closed standards and soft/hard bugs in each series of specific video hw/sw encoders and decoders. And an AI that can analyze and validate code as complex as ffmpeg has yet to be invented.

marcan_42 5y ago
It's a programming language issue. Any time you're writing complex format parsing code in an unsafe language like C, you're going to run into these problems. Unfortunately, Rust didn't exist when ffmpeg was created. Patents have absolutely nothing to do with this; they don't affect the security of the resulting code. Nobody can write code for all the formats ffmpeg supports and do it safely, in C. Nobody. You think audits work? Tell that to Infineon, who shipped a broken RSA key generator implementation. In a cryptography product. Which was audited privately. And that's a critical part of the code that should've had many eyes on it. Perfect memory safety for C parsers for hundreds of formats? Yeah, not going to happen. It has nothing to do with the code quality of ffmpeg. It's just not humanly possible to get this right in every instance.
- qayxc 5y ago
  > It's just not humanly possible to get this right in every instance. That's what theorem provers and model driven development are for. I wish these tools could be used more. There should also be automated completeness checkers for requirements and specs - a lot of errors, incompatibilities and security issues are the result of ambiguous, contradictory, or incomplete specs and requirements.
  - marcan_42 5y ago
    > That's what theorem provers and model driven development are for. That's building a safe programming language on top of an unsafe one. At that point you might as well just use a safe programming language. That won't fix logic errors, but the vast majority of security issues are safety problems, especially in this kind of codebase.
  - ellis0n 5y ago
    There is no algorithm in the world for how to check whether a video codec is working correctly or not
    - afiori 5y ago
      The model checking would not check the output but the trace of operations. It might prove that all bytes of the output were written to at least once, that dereferenced pointers point toward either the input or some other valid structure, and other properties like this.
- ellis0n 5y ago
  I agree with RSA key generator implementation idea and I like Rust is better C idea
- deleted 5y ago
  [deleted]

mikaraento 5y ago

ffmpeg/libav is being fuzzed with reasonable success. See for example https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg https://github.com/google/oss-fuzz/tree/master/projects/ffmp... and https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html https://security.googleblog.com/2014/01/ffmpeg-and-thousand-.... They found issues in code I wrote... (I work for Google but do not speak for it)