Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing GitHub Actions policies in the dumbest way possible

blog.yossarian.net

Post reply on HN
Print view View original

21–30 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#21

Post by fkyoureadthedoc »

This doesn't seem like a big deal to be honest.

My main problem with the policy and how it's implemented at my job is that the ones setting the policies aren't the ones impacted by them, and never consult people who are. Our security team tells our GitHub admin team that we can't use 3rd party actions.

Our GitHub admin team says sure, sounds good. They don't care, because they don't use actions, and they in fact don't delivery anything at all. Security team also delivers nothing, so they don't care. Combined, these teams crowning achievement is buying GitHub Enterprise and moving it back and forth between cloud and on prem 3 times in the last 7 years.

As a developer, I'll read the action I want to use, and if it looks good I just clone the code and upload it into our own org/repo. I'm already executing a million npm modules in the same context that do god knows what. If anyone complains, it's getting hit by the same static/dynamic analysis tools as the rest of the code and dependencies.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#22

Post by hiatus »

woodruffw wrote: post #4
hiatus wrote: post #2

That the policy can be "bypassed" by a code change doesn't seem so severe. If you are not reviewing changes to your CI/CD workflows all hope is lost. Your code could be exfiltrated, secrets stolen, and more.

The point of the post is that review is varied in practice: if you’re a large organization you should be reviewing the code itself for changes, but I suspect many orgs aren’t tracking every action (and every version of every action) introduced in CI/CD changes. That’s what policies are useful for, and why bypasses are potentially dangerous. Or as an intuitive framing: if you can understand the value of branch protect…

The problem is not related to tracking every action or version in CI/CD changes. Right now, you can just curl a binary and run that. How is that any different from the exploit here? I guess people may have had a false sense of security if they had implemented those policies, but I would posit those people didn't really understand their CI/CD system if they thought those policies alone would prevent arbitrary code execution.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#23

Post by clysm »

I’m not seeing the security issue here. Arbitrary code execution leads to arbitrary code execution?

Seems like policies are impossible to enforce in general on what can be executed, so the only recourse is to limit secret access.

Is there a demonstration of this being able to access/steal secrets of some sort?

Re: Bypassing GitHub Actions policies in the dumbest way possible

#24

Post by hiatus »

solumos wrote: post #9
kj4ips wrote: post #6

This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…

The implied fix to the “unusable secure system” is forking the checkout action to your org and referencing it there.

That's not a fix though is it? Git tools are already on the runner. You could checkout code from public repos using cli, and you could hardcode a token into the workflow if you wanted to access a private repo (assuming the malicious internal user doesn't have admin privileges to add a secret).

Re: Bypassing GitHub Actions policies in the dumbest way possible

#25

Post by woodruffw »

hiatus wrote: post #22
woodruffw wrote: post #4

Earlier quoted context omitted.

The point of the post is that review is varied in practice: if you’re a large organization you should be reviewing the code itself for changes, but I suspect many orgs aren’t tracking every action (and every version of every action) introduced in CI/CD changes. That’s what policies are useful for, and why bypasses are potentially dangerous. Or as an intuitive framing: if you can understand the value of branch protect…

The problem is not related to tracking every action or version in CI/CD changes. Right now, you can just curl a binary and run that. How is that any different from the exploit here? I guess people may have had a false sense of security if they had implemented those policies, but I would posit those people didn't really understand their CI/CD system if they thought those policies alone would prevent arbitrary code exe…

I think it's a difference in category; pulling random binaries from the Internet is obviously not good, but it's empirically mostly done in a pointwise manner. Actions on the other hand are pulled from a "marketplace", are subject to automatic bumps via things like Dependanbot and Renovate, can be silently rewritten thanks to tag mutability, etc.

Clearly in an ideal world runners would be hermetic. But I think the presence of other sources of non-hermeticity doesn't justify a poorly implemented policy feature on GitHub's part.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#26

Post by TheTaytay »

I don’t understand the risk honestly.

Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed to mitigate against a developer doing something malicious. Whether they clone another action into the repo or write custom scripts themselves, I don’t see how GitHub’s measures could protect against that.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#27

Post by bob1029 »

I feel like GitHub's CI/CD offering is too "all-in" now. Once we are at a point where the SCM tool is a superset of AWS circa 2010, we probably need to step back and consider alternatives.

A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for the purpose of enforcing status checks.

I would much rather write CI/CD tooling in something like python or C# than screw around with yaml files and weird shared libraries of actions. You can achieve something approximating this right now, but you would have to do it by way of GH Actions to some extent.

PRs are hardly latency sensitive, so polling a REST API once every 60 seconds seems acceptable to me. This is essentially what we used to do with Jenkins, except we'd just poll the repo head instead of some weird API.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#28

Post by lixtra »

woodruffw wrote: post #15
MadVikingGod wrote: post #13

[flagged]

The action in question is not in the repository; it's retrieved at runner execution time. I think that's an important distinction.

It’s like putting

curl -sSL https://example.com/install.sh | sh

In your action. For sure happens.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#29

Post by woodruffw »

lixtra wrote: post #28
woodruffw wrote: post #15

Earlier quoted context omitted.

The action in question is not in the repository; it's retrieved at runner execution time. I think that's an important distinction.

It’s like putting curl -sSL https://example.com/install.sh | sh In your action. For sure happens.

Yes; I would also consider that a bad idea. Two wrongs don't make a right (and a different wrong doesn't justify a broken policy elsewhere).

Re: Bypassing GitHub Actions policies in the dumbest way possible

#30

Post by woodruffw »

TheTaytay wrote: post #26

I don’t understand the risk honestly. Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed to mitigate against a developer doing something malicious. Whether they clone another action into the repo or write custom scripts themselves, I don’t see how GitHub’s measures could protect against that.

A mitigation for this exact policy mechanism is included in the post.

(The point is not directly malicious introductions: it's supply chain risk in the form of engineers introducing actions/reusable workflows that are themselves malleable/mutable/subject to risk. A policy that claims to do that should in fact do it, or explicitly document its limitations.)

Post reply on HN