Hacker News Reader

Comment by dan_manges | Hacker News Reader

GitHub Actions should use a lockfile for dependencies. Without it, compromised Actions propagate instantly. While it'd still be an issue even with locking, it would slow down the rollout and reduce the impact.

Semver notation rather than branches or tags is a great solution to this problem. Specify the version that want, let the package manager resolve it, and then periodically update all of your packages. It would also improve build stability.

View on HN

Also don't het GH actions to do anything other than build and upload artifacts somewhere. Ideally a write only role. Network level security too no open internet.

Use a seperate system for deployments. That system must be hygienic.

This isn't foolproof but would make secrets dumping not too useful. Obviously an attack could still inject crap into your artefact. But you have more time and they need to target you. A general purpose exploit probably won't hurt as much.

All the version tags got relabled to point to a compromised hash. Semver does nothing to help with this.

your build should always use hashes and not version tags of GHA's

I always use commit hashes for action versions. Dependabot handles it, it’s a no brainer.

> commit hashes

There is some latent concern that most git installations use SHA-1 hashes, as opposed to SHA-256. [0]

Also the trick of creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands.

[0] https://git-scm.com/docs/hash-function-transition

creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands

TIL; yikes! (and thanks)

A signed commit [0] might be good for internal devops stuff (e.g. "yes, we really do want this version in production") but unfortunately that's not gonna work for pulling in third-party tooling, since most won't use it.

[0]https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work

GitHub actions supports version numbers, version ranges, and even commit hashes.

The version numbers aren't immutable, so an attacker can just update the versions to point to the compromised code, which is what happened here. Commit hashes are a great idea, but you still need to be careful: lots of people use bots like Renovate to update your pinned hashes whenever a new version is published, which runs into the same problem.

I don't think that's exactly what happened here: the compromise created new tags but generally the tag consumption relies on semantic versioning

In other words: you specify version 44, the attacker creates 44.1, you're still hosed.

No you literally can (and the attackers did) change version 44 (the tag for it) to point to a different compromised commmit

Yes, you're right. I wasn't able to double-check as the repo was deleted at the time. That said, AIUI making the tags read-only would still often be vulnerable to semantic-version exploitation.

Only commit hashes are safe. In this case the bad actor changed all of the version tags to point to their malicious commit. See https://github.com/tj-actions/changed-files/tags

All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed867...

Since they edited old tags here … maybe GitHub should have some kind of security setting a repo owner can make that locks-down things like old tags so after a certain time they can't be changed.

In your GitHub Actions YAML, instead of referencing a specific tag, you can reference a specific commit. So, instead of …

    uses: actions/checkout@v4

… you can use …

    uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

That still doesn't help when the action is a docker action only marked with a tag.

So you need to check the action.yml itself to see if it has a sha256 pinned (in the case it uses Docker).

You can always just fork it and reference your own fork.

Or just write your own.

Reply on news.ycombinator.com