4 ms·

Google is, at no cost to FFMPEG: 1) dedicating compute resources to continuously fuzzing the entire project 2) dedicating engineering resources to validating

by iscoelho 11mo ago

Google is, at no cost to FFMPEG: 1) dedicating compute resources to continuously fuzzing the entire project 2) dedicating engineering resources to validating the results and creating accurate and well-informed bug reports (in this case, a seriously underestimated security issue) 3) additionally for codecs that Google likely does not even internally use or compile, purely for the greater good of FFMPEG's user base Needless to say, while I agree Google has a penny to spare to fund FFMPEG, and should (although they already contribute), I do not agree with funding this maintainer.

pjmlp 11mo ago
Then they can surely also provide a pull request for said CVE.
- SR2Z 11mo ago
  Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining? Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.
  - strictnein 11mo ago
    Personally, I want the $3.5 Trillion company to do more. So the line should be somewhere else.
    - SR2Z 11mo ago
      So you don't have a line, you just want to move the goalposts and keep moving them?
      - iscoelho 11mo ago
        It is my understanding that the commenters in FFMPEG's favor believe that Google is doing a disservice by finding these security vulnerabilities, as they require volunteer burden to patch, and that they should either: 1) allow the vulnerabilities to remain undiscovered & unpatched zero-days (stop submitting "slop" CVEs.) 2) supply the patches (which i'm sure the goalpost will move to the maintainers being upset that they have to merge them.) 3) fund the project (including the maintainers who clearly misunderstand the severity of the vulnerabilities and describe them as "slop") (no thank you.) This entire thread defies logic.
        strictnein 11mo ago
        No one is saying #1. No one is arguing against #2. #3 is something all companies with significant reliance on OSS projects should help do. The only thing that defies logic is how poorly your strawman is constructed.
        iscoelho 11mo ago
        It appears we are not reading the same thread.
      - ruined 11mo ago
        location of goalposts scales with market cap
      - strictnein 11mo ago
        Yep, that's clearly what I was saying. I want to just keep moving the goalposts (which I didn't even know I had set or moved in the first place) again and again. Or I just want the $3.5 trillion company to also provide the patches to OSS libraries/programs/etc that their projects with hundreds of millions or billions in funding happen to find. Crazy, I know.
  - angiolillo 11mo ago
    > Providing a real CVE is a contribution, not a burden. Isn't a real CVE (like any bug report) both a contribution and a burden?
    - SR2Z 11mo ago
      Only if you subscribe to the "if we stop testing, the number of cases will drop!" philosophy.
    - arcfour 11mo ago
      It's not fair to classify it as a burden; it existed anyways, but now you have the work/issue identified.
  - ahepp 11mo ago
    What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities? If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce. Maybe part of the solution is creating a separate low priority queue for bug reports from groups that could fix it but chose not to.
    - saubeidl 11mo ago
      To build on that - if it "doesn't scale" for one of the wealthiest companies in the world, it certainly doesn't scale for a volunteer project...
    - f33d5173 11mo ago
      If you are deliberately shipping insecure software, you should stop doing that. In ffmpeg's case, that means either patching the bug, or disabling the codec. They refused to do the latter because they were proud of being able to support an obscure codec. That puts the onus on them to fix the bug in it.
      - ndriscoll 11mo ago
        The ffmpeg authors aren't "shipping" anything; they're giving away something they make as a hobby with an explicit disclaimer of any kind of fitness for purpose. If someone needs something else, they can pay an engineer to make it for them.
        f33d5173 11mo ago
        This has nothing to do with payment. Not deliberately infecting your users with vulnerabilities is simply the right thing to do. Giving something away for free doesn't absolve you of certain basic ethical responsibilities.
        11mo ago
  - lenerdenator 11mo ago
    > Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor. Re-read the article. There's CVEs and then there's CVEs. This is the former, and they're shoving tons of those down the throats of unpaid volunteers while contributing nothing back. What Google's effectively doing is like a food safety inspection company going to the local food bank to get the food that they operate their corporate cafeteria on just to save a buck, then calling the health department on a monthly basis to report any and all health violations they think they might have seen, while contributing nothing of help back to the food bank.
    - SR2Z 11mo ago
      I have read the article. The expectation for a tool like ffmpeg is that regardless of what kind of file you put into it, it safely handles it. This is an actual bug in submitted code. It doesn't matter that it's for some obscure codec, it's technically maintained by the ffmpeg project and is fair game for vulnerability reports. Given that Google is also a major contributor to open-source video, this is more like a food manufacturer making sure that grocery stores are following health code when they stock their food. Mind you, the grocery store has no obligation to listen to them in this metaphor and is free to just let the report/CVE sit for a while.
    - iscoelho 11mo ago
      I am unsure why this untruth is being continuously parroted. It is false. This is exploitable on a majority of systems as the codec is enabled by default. This is a CVE that is being severely underestimated.
- gnfargbl 11mo ago
  They could, but there is really no requirement on them to do so. The security flaw was discovered by Google, but it was not created by them. Equally there is no requirement on ffmpeg to fix these CVEs nor any other. And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority.
  - lenerdenator 11mo ago
    > And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority. What's this even saying? Then they're free to fork it and never use the upstream again.
  - Y-bar 11mo ago
    > They could, but there is really no requirement on them to do so. I see this sort of sentiment daily. The sentiment that only what is strictly legal or required is what matters. Sometimes, you know, you have to recognise that there are social norms and being a good person matters and has intrinsic value. A society only governed by what the written law of the land explicitly states is a dystopia worse than hell.
    - tpmoney 11mo ago
      What's "strictly legal or required" of Google here is absolutely nothing. They didn't have to do any auditing or bug hunting. They certainly didn't have to validate or create a proper bug report, and there's no requirement whatsoever that they tell anyone about it at all. They could have found the bug, found it was being actively exploited, made their own internal patch and sat quietly by while other people remained vulnerable. All of that is well within what is "strictly legal or required". Google did more than what is "strictly legal or required", and what they did was submit a good and valid bug report. But for some reason we're mad because they didn't do even more. Why? The world is objectively a better place for having this bug report, at least now people know there's something to address.
      - 11mo ago
FridgeSeal 11mo ago
Google is: - choosing to do this of their own volition - are effectively just using their resources to throw bug reports over the wall unprompted. - benefiting from the bugs getting fixed, but not contributing to them.
- toast0 11mo ago
  > - benefiting from the bugs getting fixed, but not contributing to them. I would be very surprised if Google builds this codec when they build ffmpeg. If you run a/v codecs (like ffmpeg) in bulk, the first thing to do is sandbox the hell out of it. The second thing you do is strictly limit the containers and codecs you'll decode. Not very many people need to decode movies from old LucasArts games, for video codecs, you probably only want mpeg 1-4, h.26x, vp8, vp9, av1. And you'll want to have fuzzed those decoders as best you can too. Nobody should be surprised that there's a security problem in this ancient decoder. Many of the eclectic codecs were written to mimic how the decoders that shipped with content were written, and most of those codecs were written assuming they were decoding a known good file, because why wouldn't they be. There's no shame, that's just how it is... there's too much to proactively investigate, so someone doing fuzzing and writing excellent reports that include diagnosis, specific location of the errors, and a way to reproduce are providing a valuable contribution. Could they contribute more? Sure. But even if they don't, they've contributed something of value. If the maintainers can't or don't want to address it, that'd be reasonable too.
- iscoelho 11mo ago
  Google is a contributor to FFMPEG.
- rossjudson 11mo ago
  FFmpeg and a thousand fixes: https://j00ru.vexillium.org/2014/01/ffmpeg-and-the-tale-of-a-thousand-fixes/ https://j00ru.vexillium.org/2014/01/ffmpeg-and-the-tale-of-a... "While reading about the 4xm demuxer vulnerability, we thought that we could help FFmpeg eliminate many potential low-hanging problems from the code by making use of the Google fleet and fuzzing infrastructure we already had in place"
tofuahdude 11mo ago
FFMPEG, at no cost to Google, provided a core piece of their infrastructure for multiple multi-billion dollar product lines.
- saagarjha 11mo ago
  And this is why Google contributes back.
- woodruffw 11mo ago
  "At no cost to Google" seems difficult to substantiate, given that multiple sources indicate that Google is sponsoring FFmpeg both with engineering resources (for codec development) and cold hard cash (delivered to the FFmpeg core team via their consulting outfit[1]). This is excellent, to be clear. But it's not compatible with the yarn currently being spun of a purely extractive relationship. [1]: https://fflabs.eu https://fflabs.eu
- Ray20 11mo ago
  Yes, according to the license selected by ffmpeg. And google, according to this license selected by ffmpeg, paid them nothing. And then do some additional work, beneficial to ffmpeg.

pjmlp 11mo ago

Then they can surely also provide a pull request for said CVE.

SR2Z 11mo ago
Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining? Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.
- strictnein 11mo ago
  Personally, I want the $3.5 Trillion company to do more. So the line should be somewhere else.
  - SR2Z 11mo ago
    So you don't have a line, you just want to move the goalposts and keep moving them?
    - iscoelho 11mo ago
      It is my understanding that the commenters in FFMPEG's favor believe that Google is doing a disservice by finding these security vulnerabilities, as they require volunteer burden to patch, and that they should either: 1) allow the vulnerabilities to remain undiscovered & unpatched zero-days (stop submitting "slop" CVEs.) 2) supply the patches (which i'm sure the goalpost will move to the maintainers being upset that they have to merge them.) 3) fund the project (including the maintainers who clearly misunderstand the severity of the vulnerabilities and describe them as "slop") (no thank you.) This entire thread defies logic.
      - strictnein 11mo ago
        No one is saying #1. No one is arguing against #2. #3 is something all companies with significant reliance on OSS projects should help do. The only thing that defies logic is how poorly your strawman is constructed.
        iscoelho 11mo ago
        It appears we are not reading the same thread.
    - ruined 11mo ago
      location of goalposts scales with market cap
    - strictnein 11mo ago
      Yep, that's clearly what I was saying. I want to just keep moving the goalposts (which I didn't even know I had set or moved in the first place) again and again. Or I just want the $3.5 trillion company to also provide the patches to OSS libraries/programs/etc that their projects with hundreds of millions or billions in funding happen to find. Crazy, I know.
- angiolillo 11mo ago
  > Providing a real CVE is a contribution, not a burden. Isn't a real CVE (like any bug report) both a contribution and a burden?
  - SR2Z 11mo ago
    Only if you subscribe to the "if we stop testing, the number of cases will drop!" philosophy.
  - arcfour 11mo ago
    It's not fair to classify it as a burden; it existed anyways, but now you have the work/issue identified.
- ahepp 11mo ago
  What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities? If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce. Maybe part of the solution is creating a separate low priority queue for bug reports from groups that could fix it but chose not to.
  - saubeidl 11mo ago
    To build on that - if it "doesn't scale" for one of the wealthiest companies in the world, it certainly doesn't scale for a volunteer project...
  - f33d5173 11mo ago
    If you are deliberately shipping insecure software, you should stop doing that. In ffmpeg's case, that means either patching the bug, or disabling the codec. They refused to do the latter because they were proud of being able to support an obscure codec. That puts the onus on them to fix the bug in it.
    - ndriscoll 11mo ago
      The ffmpeg authors aren't "shipping" anything; they're giving away something they make as a hobby with an explicit disclaimer of any kind of fitness for purpose. If someone needs something else, they can pay an engineer to make it for them.
      - f33d5173 11mo ago
        This has nothing to do with payment. Not deliberately infecting your users with vulnerabilities is simply the right thing to do. Giving something away for free doesn't absolve you of certain basic ethical responsibilities.
        11mo ago
- lenerdenator 11mo ago
  > Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor. Re-read the article. There's CVEs and then there's CVEs. This is the former, and they're shoving tons of those down the throats of unpaid volunteers while contributing nothing back. What Google's effectively doing is like a food safety inspection company going to the local food bank to get the food that they operate their corporate cafeteria on just to save a buck, then calling the health department on a monthly basis to report any and all health violations they think they might have seen, while contributing nothing of help back to the food bank.
  - SR2Z 11mo ago
    I have read the article. The expectation for a tool like ffmpeg is that regardless of what kind of file you put into it, it safely handles it. This is an actual bug in submitted code. It doesn't matter that it's for some obscure codec, it's technically maintained by the ffmpeg project and is fair game for vulnerability reports. Given that Google is also a major contributor to open-source video, this is more like a food manufacturer making sure that grocery stores are following health code when they stock their food. Mind you, the grocery store has no obligation to listen to them in this metaphor and is free to just let the report/CVE sit for a while.
  - iscoelho 11mo ago
    I am unsure why this untruth is being continuously parroted. It is false. This is exploitable on a majority of systems as the codec is enabled by default. This is a CVE that is being severely underestimated.
gnfargbl 11mo ago
They could, but there is really no requirement on them to do so. The security flaw was discovered by Google, but it was not created by them. Equally there is no requirement on ffmpeg to fix these CVEs nor any other. And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority.
- lenerdenator 11mo ago
  > And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority. What's this even saying? Then they're free to fork it and never use the upstream again.
- Y-bar 11mo ago
  > They could, but there is really no requirement on them to do so. I see this sort of sentiment daily. The sentiment that only what is strictly legal or required is what matters. Sometimes, you know, you have to recognise that there are social norms and being a good person matters and has intrinsic value. A society only governed by what the written law of the land explicitly states is a dystopia worse than hell.
  - tpmoney 11mo ago
    What's "strictly legal or required" of Google here is absolutely nothing. They didn't have to do any auditing or bug hunting. They certainly didn't have to validate or create a proper bug report, and there's no requirement whatsoever that they tell anyone about it at all. They could have found the bug, found it was being actively exploited, made their own internal patch and sat quietly by while other people remained vulnerable. All of that is well within what is "strictly legal or required". Google did more than what is "strictly legal or required", and what they did was submit a good and valid bug report. But for some reason we're mad because they didn't do even more. Why? The world is objectively a better place for having this bug report, at least now people know there's something to address.
    - 11mo ago

FridgeSeal 11mo ago

Google is: - choosing to do this of their own volition - are effectively just using their resources to throw bug reports over the wall unprompted. - benefiting from the bugs getting fixed, but not contributing to them.

toast0 11mo ago
> - benefiting from the bugs getting fixed, but not contributing to them. I would be very surprised if Google builds this codec when they build ffmpeg. If you run a/v codecs (like ffmpeg) in bulk, the first thing to do is sandbox the hell out of it. The second thing you do is strictly limit the containers and codecs you'll decode. Not very many people need to decode movies from old LucasArts games, for video codecs, you probably only want mpeg 1-4, h.26x, vp8, vp9, av1. And you'll want to have fuzzed those decoders as best you can too. Nobody should be surprised that there's a security problem in this ancient decoder. Many of the eclectic codecs were written to mimic how the decoders that shipped with content were written, and most of those codecs were written assuming they were decoding a known good file, because why wouldn't they be. There's no shame, that's just how it is... there's too much to proactively investigate, so someone doing fuzzing and writing excellent reports that include diagnosis, specific location of the errors, and a way to reproduce are providing a valuable contribution. Could they contribute more? Sure. But even if they don't, they've contributed something of value. If the maintainers can't or don't want to address it, that'd be reasonable too.
iscoelho 11mo ago
Google is a contributor to FFMPEG.
rossjudson 11mo ago
FFmpeg and a thousand fixes: https://j00ru.vexillium.org/2014/01/ffmpeg-and-the-tale-of-a-thousand-fixes/ https://j00ru.vexillium.org/2014/01/ffmpeg-and-the-tale-of-a... "While reading about the 4xm demuxer vulnerability, we thought that we could help FFmpeg eliminate many potential low-hanging problems from the code by making use of the Google fleet and fuzzing infrastructure we already had in place"

tofuahdude 11mo ago

FFMPEG, at no cost to Google, provided a core piece of their infrastructure for multiple multi-billion dollar product lines.

saagarjha 11mo ago
And this is why Google contributes back.
woodruffw 11mo ago
"At no cost to Google" seems difficult to substantiate, given that multiple sources indicate that Google is sponsoring FFmpeg both with engineering resources (for codec development) and cold hard cash (delivered to the FFmpeg core team via their consulting outfit[1]). This is excellent, to be clear. But it's not compatible with the yarn currently being spun of a purely extractive relationship. [1]: https://fflabs.eu https://fflabs.eu
Ray20 11mo ago
Yes, according to the license selected by ffmpeg. And google, according to this license selected by ffmpeg, paid them nothing. And then do some additional work, beneficial to ffmpeg.