6 ms·

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 w

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.

eddythompson80 2y ago
You can always just fork it and reference your own fork.
- postalrat 2y ago
  Or just write your own.
jasonthorsness 2y ago
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.
- CaliforniaKarl 2y ago
  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
  - OptionOfT 2y ago
    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).
mceachen 2y ago
GitHub actions supports version numbers, version ranges, and even commit hashes.
- frenchtoast8 2y ago
  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.
  - marsovo 2y ago
    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.
    - BlackFingolfin 2y ago
      No you literally can (and the attackers did) change version 44 (the tag for it) to point to a different compromised commmit
      - marsovo 2y ago
        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.
- werrett 2y ago
  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 https://github.com/tj-actions/changed-files/tags All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed867 https://github.com/tj-actions/changed-files/commit/0e58ed867...
cmckn 2y ago
I always use commit hashes for action versions. Dependabot handles it, it’s a no brainer.
- Terr_ 2y ago
  > 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 https://git-scm.com/docs/hash-function-transition
  - password4321 2y ago
    creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands TIL; yikes! (and thanks)
    - Terr_ 2y ago
      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 https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work
  - deleted 2y ago
    [deleted]
mixologic 2y ago
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
nextts 2y ago
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.

eddythompson80 2y ago

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

postalrat 2y ago
Or just write your own.

jasonthorsness 2y ago

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.

CaliforniaKarl 2y ago
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
- OptionOfT 2y ago
  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).

mceachen 2y ago

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

frenchtoast8 2y ago
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.
- marsovo 2y ago
  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.
  - BlackFingolfin 2y ago
    No you literally can (and the attackers did) change version 44 (the tag for it) to point to a different compromised commmit
    - marsovo 2y ago
      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.
werrett 2y ago
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 https://github.com/tj-actions/changed-files/tags All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed867 https://github.com/tj-actions/changed-files/commit/0e58ed867...

cmckn 2y ago

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

Terr_ 2y ago
> 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 https://git-scm.com/docs/hash-function-transition
- password4321 2y ago
  creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands TIL; yikes! (and thanks)
  - Terr_ 2y ago
    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 https://git-scm.com/book/ms/v2/Git-Tools-Signing-Your-Work
- deleted 2y ago
  [deleted]

mixologic 2y ago

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

nextts 2y ago

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.