4 ms·

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in t

by simjnd 4mo ago

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

codedokode 4mo ago
If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?
- cryo32 4mo ago
  No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
  - codedokode 4mo ago
    In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.
    - uecker 4mo ago
      Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.
      - codedokode 4mo ago
        To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.
        uecker 4mo ago
        I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated structures when there is an error, but one could also automate this with a often used extension. There is also the question whether trading memory safety against supply chain risks is really worth it.
      - shermantanktop 4mo ago
        Errors are easily found and corrected for a modest one-person project in C. But we’re combining probability of error creation (which is effectively constant) and the limits of human cognition. Some things are impossible at one scale, become possible at another, and become inevitable at yet another.
  - acdha 4mo ago
    coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake. In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.
    - krageon 4mo ago
      The coreutils rewrite was shit because of the license change. Most of the other founding ideas were also bad as you say, but the license change was absolutely a much worse signal. Just a bunch of people rolling over and showing big corps their belly. And for what? So they can be more exploited by people that treat them like cattle.
    - anoneng 4mo ago
      I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple. With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.
      - zahlman 4mo ago
        > you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. True. That doesn't make them "very exposed to memory safety errors".
      - acdha 4mo ago
        My point about coreutils was that they’re rarely used in situations where an attacker can provide arbitrary input - it’s more like race conditions with code already running on the same system trying to escalate access – so what you need to protect against are things like race conditions around file operations or symlink safety.
- ivanjermakov 4mo ago
  Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance. https://news.ycombinator.com/item?id=43140614 https://news.ycombinator.com/item?id=43140614
  - IshKebab 4mo ago
    Sure but it seems like most of these vulnerabilities are being found in the C code.
    - bybrooklyn 4mo ago
      Rust could help with this!
  - leonidasrup 4mo ago
    It would be interesting to see the results from a fuzzer, developed for FFmpeg style assembly code.
LegionMammal978 4mo ago
On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through. Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.
- ftchd 4mo ago
  If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.
- sph 4mo ago
  On the third hand, pestering and shaming open-source maintainers because they don't accept your PR is how you get the XZ backdoor situation.
- xboxnolifes 4mo ago
  There is a different dynamic between this and that.
j1elo 4mo ago
Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no? I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.
- simjnd 4mo ago
  You could assume that if someone has the technical level to identify a vulnerability and how to exploit it, they probably have the technical level to fix it. In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job. FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it. It's an exhausting dynamic.

by simjnd 4mo ago

codedokode 4mo ago

If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?

cryo32 4mo ago
No. They tried that with coreutils and look what happened. More CVEs. 99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.
- codedokode 4mo ago
  In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.
  - uecker 4mo ago
    Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.
    - codedokode 4mo ago
      To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.
      - uecker 4mo ago
        I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated structures when there is an error, but one could also automate this with a often used extension. There is also the question whether trading memory safety against supply chain risks is really worth it.
    - shermantanktop 4mo ago
      Errors are easily found and corrected for a modest one-person project in C. But we’re combining probability of error creation (which is effectively constant) and the limits of human cognition. Some things are impossible at one scale, become possible at another, and become inevitable at yet another.
- acdha 4mo ago
  coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake. In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.
  - krageon 4mo ago
    The coreutils rewrite was shit because of the license change. Most of the other founding ideas were also bad as you say, but the license change was absolutely a much worse signal. Just a bunch of people rolling over and showing big corps their belly. And for what? So they can be more exploited by people that treat them like cattle.
  - anoneng 4mo ago
    I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple. With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.
    - zahlman 4mo ago
      > you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. True. That doesn't make them "very exposed to memory safety errors".
    - acdha 4mo ago
      My point about coreutils was that they’re rarely used in situations where an attacker can provide arbitrary input - it’s more like race conditions with code already running on the same system trying to escalate access – so what you need to protect against are things like race conditions around file operations or symlink safety.
ivanjermakov 4mo ago
Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance. https://news.ycombinator.com/item?id=43140614 https://news.ycombinator.com/item?id=43140614
- IshKebab 4mo ago
  Sure but it seems like most of these vulnerabilities are being found in the C code.
  - bybrooklyn 4mo ago
    Rust could help with this!
- leonidasrup 4mo ago
  It would be interesting to see the results from a fuzzer, developed for FFmpeg style assembly code.

LegionMammal978 4mo ago

On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through. Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.

ftchd 4mo ago
If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.
sph 4mo ago
On the third hand, pestering and shaming open-source maintainers because they don't accept your PR is how you get the XZ backdoor situation.
xboxnolifes 4mo ago
There is a different dynamic between this and that.

j1elo 4mo ago

Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no? I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.

simjnd 4mo ago
You could assume that if someone has the technical level to identify a vulnerability and how to exploit it, they probably have the technical level to fix it. In most cases researchers have no interest in actually "making the software better" and publishing vulns is just a way to increase their cred to land a better job. FFMPEG's position as a well know very popular open source project means it's very interesting for this type of researcher to find a vuln and put their name on it. It's an exhausting dynamic.