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

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."

"But moving to the cloud is so convenient!"

[wierd_w]

[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]

Re:

[Lady Galadriel]

[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]

Self interested Vigilantes?

[goombah99]

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

Give Google 90 mins to fix

[Sebby]

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.

Clearly you're never seen their page

[raymorris]

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?

Re:Clearly you're never seen their page

[93 Escort Wagon]

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.

Re:

[lexman098]

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.

Re:

[phantomfive]

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.

I don't get it

[jm007]

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

[wierd_w]

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.

Re:

[Un-Thesis]

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

[DarkOx]

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.

Re:

[jm007]

got it, thanks

Re:

[Programmatic]

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:

[Programmatic]

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

Re:

[wierd_w]

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

Re:

[Programmatic]

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.

Re:

[olsmeister]

or they could just sell the exploit on the dark web. what would you rather see happen?

Re:

[The New Guy 2.0]

Google gave Microsoft 90 days notice of the bug, and nothing happened. Per security tradition, this goes public.

Re:

[Anonymous Coward]

its not like they ignored it they asked for an extension. and google just said naw fuck you you'll fix it on our time line or we'll publish it for every hostile actor to exploit

Re:

[Jumperalex]

While I understand the hint of "fuck you" this might imply, do keep in mind that you're assuming no one else knows about the bug already. THAT is one of the reasons for putting pressure on and to then release. First it forces the issue to be addressed and second it notifies the user that "hey guess what, you've got a security risk that isn't being fixed and you should be aware of it so you can take your own precautions."

There really is a 100% legitimate reason for public disclosure. Reasonable people can de

Re:

[Mattcelt]

Correct.

One should never assume that they're the first person to find a bug... perhaps the first honest one, but never the first...

Re:

[account_deleted]

Comment removed based on user account deletion