Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security

Google To GitHub: Time's Up -- This Unfixed 'High-Severity' Security Bug Affects Developers (zdnet.com) 32

Google Project Zero, the Google security team that finds bugs in all popular software, has disclosed what it classes a high-severity flaw on GitHub after the code-hosting site asked for a double extension on the normal 90-day disclosure deadline. From a report: The bug in GitHub's Actions feature -- a developer workflow automation tool -- has become one of the rare vulnerabilities that wasn't properly fixed before Google Project Zero's (GPZ) standard 90-day deadline expired. Over 95.8% of flaws are fixed within the deadline, according to Google's hackers. GPZ is known to be generally strict with its 90-day deadline, but it appears GitHub was a little lax in its responses as the deadline approached after Google gave it every chance to fix the bug. As detailed in a disclosure timeline by GPZ's Felix Wilhelm, the Google security team reported the issue to GitHub's security on July 21 and a disclosure date was set for October 18. According to Wilhelm, Actions' workflow commands are "highly vulnerable to injection attacks."
This discussion has been archived. No new comments can be posted.

Google To GitHub: Time's Up -- This Unfixed 'High-Severity' Security Bug Affects Developers

Comments Filter:
  • by wierd_w ( 1375923 ) on Tuesday November 03, 2020 @11:11AM (#60679844)

    [mode=sarcastic, level=maximum]

    Surely a large company like Microsoft, who owns GitHub, would respond to a serious security risk in a timely and efficient manner! Surely they would not bet the farm on dangerously naive code that does not properly sanitize inputs, or fail to respond in a timely manner!

    I was told The Cloud was going to take over from all those other methods of organizing a workspace and toolchain, because of how much better, easier to use, and more secure it was!

    [/mode]

    • [sarcasm]
      Your first mistake was believing Microsoft would do anything that did not make money.
      And then you believed them that said the The Cloud was the way to go?
      [/sarcasm]

      [humor]
      And stop calling me Surely!
      [/humor]
  • by goombah99 ( 560566 ) on Tuesday November 03, 2020 @11:11AM (#60679848)

    Sometime Vigilante Justice is effective and needed. But the danger of it is when it becomes and outwardly directed weapon. Google seems to never release zero says on google products. I don't think this is because somehow Gmail or Gdrive, Chrome, are superior

    • Sometime Vigilante Justice is effective and needed. But the danger of it is when it becomes and outwardly directed weapon. Google seems to never release zero says on google products. I don't think this is because somehow Gmail or Gdrive, Chrome, are superior

      This is spot on - I only wish someone would find some vulnerability in a Google product, and give them 90 minutes to fix it - see how they like them apples.

    • by raymorris ( 2726007 ) on Tuesday November 03, 2020 @12:02PM (#60680034) Journal

      A few copy-pastes from the front page of Project Zero:

      Escaping the Chrome Sandbox with RIDL

      Exploiting Android Messengers with WebRTC: Part 1

      MMS Exploit Part 5: Defeating Android ASLR

      MMS Exploit Part 3: Constructing the Memory Corrup...

      Virtually Unlimited Memory: Escaping the Chrome Sandbox

      Android Messaging: A Few Bugs Short of a Chain

      Does Google normally FIX the security issues within the 90-day period? Perhaps. Does that bother you?

      • by 93 Escort Wagon ( 326346 ) on Tuesday November 03, 2020 @12:36PM (#60680182)

        I'm not going to dig them up again, but in the past I've posted several examples of Project Zero giving Google far more time (on the order of 6-12 months) to fix serious flaws. When it comes to Google, Project Zero basically only holds the line on relatively minor stuff.

        Project Zero is at some level a PR tool of Google's.

        • Maybe Microsoft should start their own Project Zero to review Google's services? The more eyes the better. As a bonus they can set whatever deadline they want for Google.
        • I'm sure you are right, but the biggest problem here is the vulnerability, not the disclosure timeframe.

          If Github hadn't written the bug in the first place, the disclosure timeframe wouldn't be a problem.
  • actually read the article, need help understanding what's going on....

    it reads like a big controversy, so thanks again msmash for the daily strife

    kept expecting the big "...or else we'll do something bad to you..." but didn't get it

    what gives?

    • Re:I don't get it (Score:5, Informative)

      by wierd_w ( 1375923 ) on Tuesday November 03, 2020 @11:29AM (#60679916)

      Google's pet hacking team discovered an injection attack vulnerability in GitHub's team management software. Typically, this kind of vunlerability allows an attacker to execute arbitrary command line invocations on a target platform's underlying operating system, allowing an attacker to instruct it to download a payload, and then execute it, for instance.

      This is very bad juju, and is why any web-oriented or web-facing user portal needs to fully sanitize its inputs. However in practice, "lowest bidder" fuckups always seem to happen, and that kind of security validation is never performed.

      Because this could lead to GitHub's server farm getting raped hard by any number of malicious agents, they discretely disclosed it to GitHub's appropriate staffing, who then did absolutely nothing to fix it.

      This team has a normal operating policy to publicly disclose such vulnerabilities, to light fires under particularly lazy asses, after 90 days.

      90 days elapsed, and to prove that they are actually nice people, the google team gave a little more time.

      Still "Fuck all" was done, so they released details of the vulnerability.

      Now GitHub's servers are in danger of being the subject of a Chuck Tingle novel.

      • It's because, at worse, it would almost certainly only affect Docker containers.

        Who cares?! Certainly not GitHub.

        This is a big headline grabber nothing.

        • Re:I don't get it (Score:5, Insightful)

          by DarkOx ( 621550 ) on Tuesday November 03, 2020 @12:02PM (#60680038) Journal

          Yeah who cares! You do realize a container doing anything useful for the most part is going to have access to some data store right?, its not like its truly a sealed box! Sure it might limit the blast radius but its virtually certain something someone cares about is in fact exposed, the container service might address the availability issues, but compromised container still represents and confidentiality or integrity issue, or both in most cases.

          Then there is a little matter of exploiting github in general. Lots of third parties trust github to some degree. Even if they just let software developers connect to it by proxy or whatever. Just being able to run code there might allow you to either exploit one of those trust relationships -or- evade detection, as traffic proxied thru github might way less suspicious to SEIM systems and the like than traffic from elsewhere.

      • by jm007 ( 746228 )

        got it, thanks

      • The only GitHub servers executing GitHub Actions are fresh CI agents; users are allowed to execute arbitrary code on those anyhow. The actual danger is untrusted code executing in the context of a user's CI context which can allow user secrets to be exfiltrated and used, or if you can execute code on an organization's trusted runners that have secrets on the runner itself.
    • Re: (Score:3, Informative)

      GitHub Actions is a CI tool that executes a yaml file that describes the things to be performed to do interesting work such as building your bits and publishign them to a package provider or managing issues on GitHub itself. The file contains directives to perform interesting tasks in a composable way: you can make a self-contained "action" that executes using inputs to perform these tasks and sets outputs for future actions. Actions uses an in-band control mechanism to do things like set environment variab
      • It could also be used for more pedestrian DDoS uses (gives you a datacenter grade pipe to do such things with), or to do bitcoin mining at Microsoft's expense (since the program is executing on their iron clandestinely), or any number of other things that executing arbitrary code on an internet connected platform would facilitate.

        The severity of the injection is greatly diminished if it is contained within a context that the attacker "owns"-- However, if that context can be escalated, then this becomes as c

        • You can already do that today; just write an Action to do that and use GitHub's runners to do whatever you want. There is no need to use another GitHub user's CI to execute arbitrary code: you can just write your own workflow to do it and run it for free.
  • Comment removed based on user account deletion

This is the theory that Jack built. This is the flaw that lay in the theory that Jack built. This is the palpable verbal haze that hid the flaw that lay in...

Working...