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

How to harden GitHub Actions

wiz.io

Post reply on HN
Print view View original

21–30 of 74 posts

Re: How to harden GitHub Actions

#21

Post by axelfontaine »

This is a great article, with many important points.

One nitpick:

> Self-hosted runners should never be used with public repositories.

Public repositories themselves aren't the issue, pull requests are. Any infrastructure or data mutable by a workflow involving pull requests should be burned to the ground after that workflow completes. You can achieve this with ephemeral runners with JIT tokens, where the complete VM is disposed of after the job completes.

As always the principle of least-privilege is your friend.

If you stick to that, ephemeral self-hosted runners on disposable infrastructure are a solid, high-performance, cost-effective choice.

We built exactly this at Sprinters [0] for your own AWS account, but there are many other good solutions out there too if you keep this in mind.

[0] https://sprinters.sh

Re: How to harden GitHub Actions

#22

Post by wongarsu »

tomrod wrote: post #4
guappa wrote: post #3

Earlier quoted context omitted.

We use linux distributions.

How do apt, dnf, and apk prevent malicious software from getting into repositories?

In principle by having the repository maintainer review the code they are packaging. They can't do a full security review of every package and may well be fooled by obfuscated code or deliberately introduced bugs, but the threshold for a successful attack is much higher than on Github Actions or npm.

Re: How to harden GitHub Actions

#23

Post by cyrnel »

This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process.

You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the thing they are designed to do and nothing more.

There's essentially nothing nefarious changed-files could do if it were limited to merely reading a git diff provided to it on stdin.

Github provides no mechanism to do this, probably because posts like this one never even call out the glaring omission of a sandboxing feature.

Re: How to harden GitHub Actions

#24

Post by cedws »

Arch-TK wrote: post #14

The recommendation is not to interpolate certain things into shell scripts. Don't interpolate _anything_ into shell scripts as a rule. Use environment variables. This combined with people having no clue how to write bash well/safely is a major source of security issues in these things.

Zizmor has a check for this.

https://github.com/woodruffw/zizmor

Re: How to harden GitHub Actions

#25

Post by KronisLV »

wongarsu wrote: post #22
tomrod wrote: post #4

Earlier quoted context omitted.

How do apt, dnf, and apk prevent malicious software from getting into repositories?

In principle by having the repository maintainer review the code they are packaging. They can't do a full security review of every package and may well be fooled by obfuscated code or deliberately introduced bugs, but the threshold for a successful attack is much higher than on Github Actions or npm.

It kinda feels like any CI/CD should only be run on the server after one of the maintainers gives it the okay to do so, after reviewing the code. From this, one can also make the assumption that most of the CI (linting, various checks and tests) should all be runnable locally even before any code is pushed.

Re: How to harden GitHub Actions

#26

Post by carlmr »

ratrocket wrote: post #20
KolmogorovComp wrote: post #16

Earlier quoted context omitted.

Because reading the code is useless if you can't pin the version, and the article explains well it's hard to do > However, only hash pinning ensures the same code runs every time. It is important to consider transitive risk: even if you hash pin an Action, if it relies on another Action with weaker pinning, you're still exposed.

Depending on your circumstances (and if the license of the action allows it) it's "easy" to fork the action and use your own fork. Instant "pinning".

But how does that solve the issue with the forked action not using pinned versions itself.

You need to recursively fork and modify every version of the GHA and do that to its sub-actions.

You'd need something like a lockgile mechanism to prevent this.

Re: How to harden GitHub Actions

#28

Post by mdaniel »

cedws wrote: post #11
DGAP wrote: post #5

Great article! I also found this open source tool for sandboxing to be useful: https://github.com/bullfrogsec/bullfrog

I came across this the other day but I couldn’t really grok how it works. Does it run at a higher privilege level than the workflow or the same? Can a sophisticated enough attack just bypass it?

I spent a few seconds clicking into it before the newfound 429 responses from GitHub caused me to lose interest

I believe a sufficiently sophisticated attacker could unwind the netfilter and DNS change, but in my experience every action that you're taking during a blind attack is one more opportunity for things to go off the rails. The increased instructions (especially ones referencing netfilter and DNS changes) also could make it harder to smuggle in via an obfuscated code change (assuming that's the attack vector)

That's a lot of words to say that this approach could be better than nothing, but one will want to weigh its gains against the onoz of having to keep its allowlist rules up to date in your supply chain landscape

Re: How to harden GitHub Actions

#29

Post by bob1029 »

> By default, the Workflow Token Permissions were set to read-write prior to February 2023. For security reasons, it's crucial to set this to read-only. Write permissions allow Workflows to inadvertently or maliciously modify your repository and its data, making least-privilege crucial.

> Double-check to ensure this permission is set correctly to read-only in your repository settings.

It sounds to me like the most secure GH Action is one that doesn't need to exist in the first place. Any time the security model gets this complicated you can rest assured that it is going to burn someone. Refer to Amazon S3's byzantine configuration model if you need additional evidence of this.

Re: How to harden GitHub Actions

#30

Post by ebfe1 »

After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version

https://github.com/santrancisco/pmw

It has a few "features" which allowed me to go through a repository quickly:

- It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code if needed

- Once you accept a change, it will keep that in a json file so future exact vesion of the action will be pinned as well and won't be reprompted.

- It let you also ignore version tag for github actions coming from well-known, reputational organisation (like "actions" belong to github) - as you may want to keep updating them so you receive hotfix if something not backward compatible or security fixes.

This way i have full control of what to pin and what not and then this config file is stored in .github folder so i can go back, rerun it again and repin everything.

Post reply on HN