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

31–40 of 129 posts

Re: Bypassing GitHub Actions policies in the dumbest way possible

#31

Post by korm »

bob1029 wrote: post #27

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 to…

GitHub has both webhooks and an extensive API. What you are describing is entirely doable, nothing really requires GitHub Actions as far as I know.

Most people opt for it for convenience. There's a balance you can strike between all the yaml and shared actions, and running your own scripts.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#32

Post by formerly_proven »

qbane wrote: post #17
ghusto wrote: post #11

> world’s dumbest policy bypass: instead of doing uses: actions/checkout@v4, the user can git clone (or otherwise fetch) the actions/checkout repository into the runner’s filesystem, and then use uses: ./path/to/checkout to run the very same action Good lord. This is akin to saying "Instead of doing `apt-get install `, one can bypass the apt policies by downloading the package and running `dpkg -i `.

Also you can leak any secrets by making connections to external services via internet and simply send secrets to them.

Not in many enterprisey CI systems you can't, those frequently have hermetic build environments.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#34

Post by [deleted] »

fkyoureadthedoc wrote: post #21

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'…

[deleted]

Re: Bypassing GitHub Actions policies in the dumbest way possible

#35

Post by mook »

fkyoureadthedoc wrote: post #21

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'…

It sounds like reading the code and forking it (therefore preventing malicious updates) totally satisfies the intent behind the policy, then.

My company has a similar whitelist of actions, with a list of third-party actions that were evaluated and rejected. A lot of the rejected stuff seems to be some sort of helper to make a release, which pretty much has a blanket suggestion to use the `gh` CLI already on the runners.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#36

Post by msgodel »

formerly_proven wrote: post #32
qbane wrote: post #17

Earlier quoted context omitted.

Also you can leak any secrets by making connections to external services via internet and simply send secrets to them.

Not in many enterprisey CI systems you can't, those frequently have hermetic build environments.

Nothing makes me want to quit software more than enterprisey CI systems.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#37

Post by dijksterhuis »

clysm wrote: post #23

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?

It's less of an "use this to do nasty shit to a bunch of unsuspecting victims" one, and more of a "people can get around your policies when you actually need policies that limit your users".

1. BigEnterpriseOrg central IT dept click the tick boxes to disable outside actions because compliance requires not using external actions [0]

2. BigBrainedDeveloper wants to use ExternalAction, so uses the method documented in the post because they have a big brain

3. BigEnterpriseOrg is no longer compliant with and, more importantly, the central IT dept have zero idea this is happening without continuously inspecting all the CI workflows for every team they support and signing off on all code changes [1]

That's why someone else's point of "you're supposed to fork the action into your organisation" is a solution if disabling local `uses:` is added as an option in the tick boxes -- the central IT dept have visibility over what's being used and by whom if BigBrainedDeveloper can ask for ExternalAction to be forked into BigEnterpriseOrg GH organisation. Central IT dept's involvement is now just review the codebase, fork it, maintain updates.

NOTE: This is not a panacea against all things that go against compliance (downloading external binaries etc). But it would be an easy gap getting closed.

----

[0]: or something, i dunno, plenty of reasons enterprise IT depts do stuff that frustrates internal developers

[1]: A sure-fire way to piss off every single one of your internal developers.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#38

Post by qbane »

formerly_proven wrote: post #32
qbane wrote: post #17

Earlier quoted context omitted.

Also you can leak any secrets by making connections to external services via internet and simply send secrets to them.

Not in many enterprisey CI systems you can't, those frequently have hermetic build environments.

I think GitHub is correct that the bypass itself is not a vulnerability, but just like the little tooltip on GitHub's "create secret gist" button, GitHub can do a better job clarifying at the "Actions permissions" section.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#39

Post by mystifyingpoi »

qbane wrote: post #17
ghusto wrote: post #11

> world’s dumbest policy bypass: instead of doing uses: actions/checkout@v4, the user can git clone (or otherwise fetch) the actions/checkout repository into the runner’s filesystem, and then use uses: ./path/to/checkout to run the very same action Good lord. This is akin to saying "Instead of doing `apt-get install `, one can bypass the apt policies by downloading the package and running `dpkg -i `.

Also you can leak any secrets by making connections to external services via internet and simply send secrets to them.

You can also print them to console in quadruple base64 in reverse, the trick is getting away with it.

Re: Bypassing GitHub Actions policies in the dumbest way possible

#40

Post by mystifyingpoi »

clysm wrote: post #23

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?

> Seems like policies are impossible to enforce

The author relates to exactly that: "ineffective policy mechanisms are worse than missing policy mechanisms, because they provide all of the feeling of security through compliance while actually incentivizing malicious forms of compliance."

And I totally agree. It is so abundant. "Yes, we are in compliance with all the strong password requirements, strictly speaking there is one strong password for every single admin user for all services we use, but that's not in the checklist, right?"

Post reply on HN