5 ms·

I've often heard HNers state that Project Zero is unwilling/uninterested in protecting the interests of the vulnerable host, but this seems like an excellent ca

by sounds 6y ago

I've often heard HNers state that Project Zero is unwilling/uninterested in protecting the interests of the vulnerable host, but this seems like an excellent case study where Github, the host, just doesn't think this is a big deal. I think that applies to any host who doesn't patch their vulnerabilities - if they thought it was a big deal, they'd do something about it. Actions speak. Quoting from the post: 2020-07-21 Report sent to Github and triaged by Github security team. Disclosure date is set for 2020-10-18. 2020-08-13 Project Zero requests a status update. 2020-08-21 Github say that they are are still working on a fix and a deprecation plan 2020-10-01 Github issued an advisory[1] deprecating the vulnerable commands, assigned CVE-2020-15228, and asked users to patch and update their workflows. 2020-10-12 Project Zero reach out and proactively mentions that a grace period is available if Github wants more time to disable the vulnerable commands. 2020-10-16 Github requested the additional 14 day grace period, with the hope of disabling the vulnerable commands after 2020-10-19. 2020-10-16 Project Zero grants grace period, new disclosure date is 2020-11-02. 2020-10-28 Project Zero reaches out, noting the deadline expires next week. No response is received. 2020-10-30 Due to no response and the deadline closing in, Project Zero reaches out to other informal Github contacts. The response is that the issue is considered fixed and that we are clear to go public on 2020-11-02 as planned. 2020-11-01 Github responds and mentions that they won't be disabling the vulnerable commands by 2020-11-02. They request an additional 48 hours, not to fix the issue, but to notify customers and determine a "hard date" at some point in the future. 2020-11-02 Project Zero responds that there is no option to further extend the deadline as this is day 104 (90 days + 14 day grace extension) and that the disclosure will be today.

zenexer 6y ago
Indeed, if that timeline is to be believed—and I have no reason to doubt it—it’s pretty damning. GitHub just kept putting it off. When they asked to delay the disclosure indefinitely at the very last second, of course they were told that would be unacceptable.
- naikrovek 6y ago
  I dunno. I've worked in many places that ABSOLUTELY had the desire, willingness, money, time, and ability to do something, and were still unable to make that thing happen, for reasons that can't be spoken about. While it is true that if an entire organization wants something done that it will happen, it is not true that inaction by an organization always signifies unwillingness or inability to act. It's easy to sit on the sidelines and throw tomatoes at the parties involved. It is another matter entirely when you are hamstrung by internal process or a specific power-tripping and ignorant person in management.
  - nemetroid 6y ago
    > It is another matter entirely when you are hamstrung by internal process or a specific power-tripping and ignorant person in management. That still sounds like unwillingness or inability to me.
  - saghm 6y ago
    If that were the case, I feel like Github should have responded on 10-28, when Project Zero reached out mentioning that the deadline was approaching. If they asked for another extension then rather than just not responding, maybe Project Zero would have considered being more accommodating?
  - ikawe 6y ago
    Even if there exists some really well intentioned hamstrung individuals within the organization, I think it's desirable to highlight and potentially shame institution as a whole that aren't able to effectively mobilize. What's the viable alternative?
  - izacus 6y ago
    >While it is true that if an entire organization wants something done that it will happen, it is not true that inaction by an organization always signifies unwillingness or inability. It's easy to sit on the sidelines and throw tomatoes at the parties involved. It is another matter entirely when you are hamstrung by internal process or a specific power-tripping and ignorant person in management. The thing is, major releases and public shaming is pretty much the only thing that has a (not guaranteed) chance of moving these processes or stubborn people. Before that they learn to just delay indefinately.
hn_throwaway_99 6y ago
I mean, in this case what difference does the Project Zero disclosure make? I've been getting alerts about my Actions build, GitHub has released the functionality necessary to implement the change, and GitHub has had a website explaining the vulnerability for weeks now. This isn't a case where disclosure actually disclosed anything new. Edit: For reference, this was announced on the GitHub blog a month ago: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/ https://github.blog/changelog/2020-10-01-github-actions-depr...
- sounds 6y ago
  I would say it seems Github thought it would make a difference, based on their request for 48 more hours. Why do you think it won't make a difference to them in light of them specifically requesting 48 more hours?
  - hn_throwaway_99 6y ago
    Because of that 2nd to last point: > Github responds and mentions that they won't be disabling the vulnerable commands by 2020-11-02. They request an additional 48 hours, not to fix the issue, but to notify customers and determine a "hard date" at some point in the future. The issue isn't really with GitHub not making the fix available, but the issue is that if they turn it off now they will break legions of builds. I think the Project Zero disclosure issue for them then is more for pointy haired manager appearances ("Oh no! Github has a disclosed Project Zero vuln!") than for any real difference in security.
    - ryanseys 6y ago
      Then break the legion of builds in the name of security.
      - hn_throwaway_99 6y ago
        That seems along the lines of "I can just turn off the ability to log in to prevent account hacking!" level of security thinking.
jacobsenscott 6y ago
I'm impressed github replied at all. I've never received a response on a github support ticket. I don't think they are even monitored.
- francislavoie 6y ago
  I have plenty of times actually. I've given lots of feedback for the github android app and gotten great responses. And most of the user reports (spam users etc) get dealt with within a couple days.
- oefrha 6y ago
  I’ve sent dozens of support tickets over the decade, and can’t recall ever not receiving a response, including on minor feature requests or bug reports (e.g. once there was this minor UI issue where scrolling causes certain UI elements to jump around on iOS Safari, or something like that). At the very least I would get an acknowledgement that the issue has been filed with the appropriate team. We must live in alternate universes, or somehow my nothing special personal account (free at first, $7/mo since 2015 or so) is prioritized, or somehow your account is deprioritized.
- the_duke 6y ago
  I reported a minor GraphQL API issue a while ago, which was actually my fault (incorrect usage), and received a helpful response within 30 minutes.
kbenson 6y ago
> I've often heard HNers state that Project Zero is unwilling/uninterested in protecting the interests of the vulnerable host I think that's usually people that just vastly prioritize the interests of the vulnerable host compared to the interests of all the users. To my eyes it's obvious there's a trade-off to be made between protecting the company and protecting the people affected. Too little time is detrimental to one party (sometimes both to some degree), while too much time is definitely detrimental to the other. It's a fine line to walk, but the best thing you can do is be consistent. Nobody is served well if the companies/projects in question work under the assumption that more time will be given because it has to others in the past, and then it isn't, as the company may not have correctly prioritized the fix, and then the public is left vulnerable as well. But to not be consistent leads to abuses of the system where things just don't get fixed. At this point, I don't think anyone can accuse Project Zero of being inconsistent, and 90 days is a long time to get something fixed if you put the resources towards it that it needs. I have little sympathy for a company that mismanages this process at this point. For an open source project, there's always groups and lists you can go to and ask for help if it seems overwhelming for the project you have. Presumably if it's an important enough project some person or company that cares about it will donate some time. If nobody is willing then my guess is that the project's not that important to people. There's also the possibility that the problem is so large or so fundamental that fixing it is a herculean task. Maybe in that case people are better off moving to an alternative if they care about the problem. Sometimes things are so bad the best choice is just to jump ship. It sucks for that company or project, but they have no right to my usage, but I do have a right to choose what I want.
zelon88 6y ago
You're assuming the goal of Project Zero is to take an interest or willingness to protect vulnerable hosts. That is not the goal of Google Project Zero. The goal is to find vulnerabilities that impact the stock price of Alphabet competitors, usually Microsoft or Apple.
- tester34 6y ago
  There's also more "good faith" take on that: The software of their competitors is used by billions of people, thus finding and reporting vulns in that software is going to help billions of people by fixing that problem.
  - zelon88 6y ago
    If that was actually the case then, just by the numbers, wouldn't they spend all their time fuzzing Android or GSuit or their own codebases as well? Or at least release the reports of them with the same viritol? It's like Toyota buying a Ford and finding out that if you rear end it, it will explode. So Toyota publishes their finding. Then weeks later a 3rd party finds the prius accelerates by itself. Maybe if Toyota wasn't so busy trying to screw Ford they would have known about their own glaring issues. We can't tell whether or not Google lives in a glass house because they keep it proprietary. Therefore we need to assume it's no better than what they bully others for. Nobody handed Google a crown and made them ruler of everyone's code. They just kinda built themselves a castle and started cutting off heads.

by sounds 6y ago

zenexer 6y ago

Indeed, if that timeline is to be believed—and I have no reason to doubt it—it’s pretty damning. GitHub just kept putting it off. When they asked to delay the disclosure indefinitely at the very last second, of course they were told that would be unacceptable.

naikrovek 6y ago
I dunno. I've worked in many places that ABSOLUTELY had the desire, willingness, money, time, and ability to do something, and were still unable to make that thing happen, for reasons that can't be spoken about. While it is true that if an entire organization wants something done that it will happen, it is not true that inaction by an organization always signifies unwillingness or inability to act. It's easy to sit on the sidelines and throw tomatoes at the parties involved. It is another matter entirely when you are hamstrung by internal process or a specific power-tripping and ignorant person in management.
- nemetroid 6y ago
  > It is another matter entirely when you are hamstrung by internal process or a specific power-tripping and ignorant person in management. That still sounds like unwillingness or inability to me.
- saghm 6y ago
  If that were the case, I feel like Github should have responded on 10-28, when Project Zero reached out mentioning that the deadline was approaching. If they asked for another extension then rather than just not responding, maybe Project Zero would have considered being more accommodating?
- ikawe 6y ago
  Even if there exists some really well intentioned hamstrung individuals within the organization, I think it's desirable to highlight and potentially shame institution as a whole that aren't able to effectively mobilize. What's the viable alternative?
- izacus 6y ago
  >While it is true that if an entire organization wants something done that it will happen, it is not true that inaction by an organization always signifies unwillingness or inability. It's easy to sit on the sidelines and throw tomatoes at the parties involved. It is another matter entirely when you are hamstrung by internal process or a specific power-tripping and ignorant person in management. The thing is, major releases and public shaming is pretty much the only thing that has a (not guaranteed) chance of moving these processes or stubborn people. Before that they learn to just delay indefinately.

hn_throwaway_99 6y ago

I mean, in this case what difference does the Project Zero disclosure make? I've been getting alerts about my Actions build, GitHub has released the functionality necessary to implement the change, and GitHub has had a website explaining the vulnerability for weeks now. This isn't a case where disclosure actually disclosed anything new. Edit: For reference, this was announced on the GitHub blog a month ago: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/ https://github.blog/changelog/2020-10-01-github-actions-depr...

sounds 6y ago
I would say it seems Github thought it would make a difference, based on their request for 48 more hours. Why do you think it won't make a difference to them in light of them specifically requesting 48 more hours?
- hn_throwaway_99 6y ago
  Because of that 2nd to last point: > Github responds and mentions that they won't be disabling the vulnerable commands by 2020-11-02. They request an additional 48 hours, not to fix the issue, but to notify customers and determine a "hard date" at some point in the future. The issue isn't really with GitHub not making the fix available, but the issue is that if they turn it off now they will break legions of builds. I think the Project Zero disclosure issue for them then is more for pointy haired manager appearances ("Oh no! Github has a disclosed Project Zero vuln!") than for any real difference in security.
  - ryanseys 6y ago
    Then break the legion of builds in the name of security.
    - hn_throwaway_99 6y ago
      That seems along the lines of "I can just turn off the ability to log in to prevent account hacking!" level of security thinking.

jacobsenscott 6y ago

I'm impressed github replied at all. I've never received a response on a github support ticket. I don't think they are even monitored.

francislavoie 6y ago
I have plenty of times actually. I've given lots of feedback for the github android app and gotten great responses. And most of the user reports (spam users etc) get dealt with within a couple days.
oefrha 6y ago
I’ve sent dozens of support tickets over the decade, and can’t recall ever not receiving a response, including on minor feature requests or bug reports (e.g. once there was this minor UI issue where scrolling causes certain UI elements to jump around on iOS Safari, or something like that). At the very least I would get an acknowledgement that the issue has been filed with the appropriate team. We must live in alternate universes, or somehow my nothing special personal account (free at first, $7/mo since 2015 or so) is prioritized, or somehow your account is deprioritized.
the_duke 6y ago
I reported a minor GraphQL API issue a while ago, which was actually my fault (incorrect usage), and received a helpful response within 30 minutes.

kbenson 6y ago

> I've often heard HNers state that Project Zero is unwilling/uninterested in protecting the interests of the vulnerable host I think that's usually people that just vastly prioritize the interests of the vulnerable host compared to the interests of all the users. To my eyes it's obvious there's a trade-off to be made between protecting the company and protecting the people affected. Too little time is detrimental to one party (sometimes both to some degree), while too much time is definitely detrimental to the other. It's a fine line to walk, but the best thing you can do is be consistent. Nobody is served well if the companies/projects in question work under the assumption that more time will be given because it has to others in the past, and then it isn't, as the company may not have correctly prioritized the fix, and then the public is left vulnerable as well. But to not be consistent leads to abuses of the system where things just don't get fixed. At this point, I don't think anyone can accuse Project Zero of being inconsistent, and 90 days is a long time to get something fixed if you put the resources towards it that it needs. I have little sympathy for a company that mismanages this process at this point. For an open source project, there's always groups and lists you can go to and ask for help if it seems overwhelming for the project you have. Presumably if it's an important enough project some person or company that cares about it will donate some time. If nobody is willing then my guess is that the project's not that important to people. There's also the possibility that the problem is so large or so fundamental that fixing it is a herculean task. Maybe in that case people are better off moving to an alternative if they care about the problem. Sometimes things are so bad the best choice is just to jump ship. It sucks for that company or project, but they have no right to my usage, but I do have a right to choose what I want.

zelon88 6y ago

You're assuming the goal of Project Zero is to take an interest or willingness to protect vulnerable hosts. That is not the goal of Google Project Zero. The goal is to find vulnerabilities that impact the stock price of Alphabet competitors, usually Microsoft or Apple.

tester34 6y ago
There's also more "good faith" take on that: The software of their competitors is used by billions of people, thus finding and reporting vulns in that software is going to help billions of people by fixing that problem.
- zelon88 6y ago
  If that was actually the case then, just by the numbers, wouldn't they spend all their time fuzzing Android or GSuit or their own codebases as well? Or at least release the reports of them with the same viritol? It's like Toyota buying a Ford and finding out that if you rear end it, it will explode. So Toyota publishes their finding. Then weeks later a 3rd party finds the prius accelerates by itself. Maybe if Toyota wasn't so busy trying to screw Ford they would have known about their own glaring issues. We can't tell whether or not Google lives in a glass house because they keep it proprietary. Therefore we need to assume it's no better than what they bully others for. Nobody handed Google a crown and made them ruler of everyone's code. They just kinda built themselves a castle and started cutting off heads.