4 ms·

People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.

by remram 2y ago

harrisi 2y ago
Aren't GitHub action "packages" designate by a single major version? Something like checkout@v4, for example. I thought that that designated a single release as v4 which will not be updated? I'm quite possibly wrong, since I try to avoid them as much as I can, but I mean.. wow I hope I'm not.
- remram 2y ago
  No the "v4" tag gets updated from v4.1 to v4.2 etc as those minor versions are released. They are branches, functionally.
  - harrisi 2y ago
    Wow, thank you (and the other person that pointed this out to me). That's madness.
    - semiquaver 2y ago
      You can pin actions to a git sha to prevent this but people generally do not. Action authors would prefer their updates be picked up automatically.
  - werrett 2y ago
    Exactly. And that's what happened here -- the bad actor changed all of those 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/0e58ed8671d6b60d0890c21b07f8835ace038e67#diff-3d2b59189eeedc2d428ddd632e97658fe310f587f7cb63b01f9b98ffc11c0197R2999 https://github.com/tj-actions/changed-files/commit/0e58ed867...
    - diggan 2y ago
      Correct me if I'm wrong, but you would be able to prevent this specific issues with the "Rules" in order to block updates of tags; https://github.blog/news-insights/product-news/github-repository-rules-are-now-generally-available/ https://github.blog/news-insights/product-news/github-reposi...
      - sestep 2y ago
        Yeah but no GitHub Action is going to do this because updating tags is the de facto mechanism for releasing patches for those repositories.
jakub_g 2y ago
I think a big part of the problem is the way one typically "installs" a GH action: by copy-pasting something from README of the action. Let's have a look at a random official GH provided action: https://github.com/actions/checkout https://github.com/actions/checkout It lists the following snippet: `uses: actions/checkout@v4` Almost everyone will just copy paste this snippet and call it a day. Most people don't think twice that v4 is a movable target that can be compromised. In case of npm/yarn deps, one would often do the same, and copy paste `yarn install foobar`, but then when installing, npm/yarn would create a lockfile and pin the version. Whereas there's no "installer" CLI for GH actions that would pin the version for you, you just copy-paste and git push. To make things better, ideally, the owners of actions would update the workflows which release a new version of the GH action, to make it update README snippet with the sha256 of the most recent release, so that it looks like `uses: actions/checkout@abcdef9876543210` # v4.5.6 Since GitHub doesn't promote good defaults, it's not surprising that third-party maintainers do the same.
- xign 2y ago
  I mean, I think there's a difference between trusting GitHub and trusting third parties. If I can't trust GitHub, then there's absolutely no point in hosting on GitHub or trusting anything in GitHub Actions to begin with. But yes I do think using tags is problematic. I think for one, GitHub should ban re-tagging. I can't think of a good reason for a maintainer to re-publish a tag to another commit without malicious intent. Otherwise they should provide a syntax to pin to both a tag and a commit, something like this: `uses: actions/checkout@v4.5.6@abcdef9876543210` The action should only work if both conditions are satisfied. This way you can still gain semantics version info (so things like dependabot can work to notify an update) but the commit is still pinned. --- I do have to say though, these are all just band-aids on top of the actual issue. If you are actually using a dependency that is compromised, someone is going to get screwed. Are you really going to read through the commit and the source code to scan for suspicious stuff? I guess if someone else got screwed before you did they may report it, but it's still fundamentally an issue here. The simple answer is "don't use untrustworthy repositories" but that is hard to guarantee. Only real solution is to use as few dependencies as possible.
0rzech 2y ago
Some people do actually pin versions, like me. For instance: - uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7 or - uses: subosito/flutter-action@f2c4f6686ca8e8d6e6d0f28410eeef506ed66aff # v2.18.0 It's a bit more manual work, but lepiej dmuchać na zimne (lit. it is better to blow on something cold), as the Polish proverb says.
- brokenpip3 2y ago
  >It's a bit more manual work after this incident, I started pinning all my github workflows with hashes, like other folks here I guess :D But I quickly got tired of doing it manually so I put together this [0] quick and dirty script to handle it for me. It just updates all workflow files in a repo and can be also used as a pre-commit hook to catch any unpinned steps in the future. It’s nothing fancy (leveraging ls-remote), but it’s saved me some time, so I figured I’d share in case it helps someone else :) [0] https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov-file#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov...
  - 0rzech 2y ago
    > github action dependency with the hash of the specific tag and a human readable tag that dependabot will keep/update in the future [1] Allowing bots to do that is going to make you vulnerable to such attacks anyway. [1] https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657bd43b5043994cf981b216374c15f6ef3/README.md#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657...
- matsemann 2y ago
  You would still be exposed if you had renovate or dependabot make a PR where they update the hash for you, though. Here's a PR we got automatically created the other day: -uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3 +uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3 and this PR gets run with privileges since it's from a user with write permissions.
  - 2y ago

People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.

by remram 2y ago

People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.

harrisi 2y ago

Aren't GitHub action "packages" designate by a single major version? Something like checkout@v4, for example. I thought that that designated a single release as v4 which will not be updated? I'm quite possibly wrong, since I try to avoid them as much as I can, but I mean.. wow I hope I'm not.

remram 2y ago
No the "v4" tag gets updated from v4.1 to v4.2 etc as those minor versions are released. They are branches, functionally.
- harrisi 2y ago
  Wow, thank you (and the other person that pointed this out to me). That's madness.
  - semiquaver 2y ago
    You can pin actions to a git sha to prevent this but people generally do not. Action authors would prefer their updates be picked up automatically.
- werrett 2y ago
  Exactly. And that's what happened here -- the bad actor changed all of those 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/0e58ed8671d6b60d0890c21b07f8835ace038e67#diff-3d2b59189eeedc2d428ddd632e97658fe310f587f7cb63b01f9b98ffc11c0197R2999 https://github.com/tj-actions/changed-files/commit/0e58ed867...
  - diggan 2y ago
    Correct me if I'm wrong, but you would be able to prevent this specific issues with the "Rules" in order to block updates of tags; https://github.blog/news-insights/product-news/github-repository-rules-are-now-generally-available/ https://github.blog/news-insights/product-news/github-reposi...
    - sestep 2y ago
      Yeah but no GitHub Action is going to do this because updating tags is the de facto mechanism for releasing patches for those repositories.

jakub_g 2y ago

I think a big part of the problem is the way one typically "installs" a GH action: by copy-pasting something from README of the action. Let's have a look at a random official GH provided action: https://github.com/actions/checkout https://github.com/actions/checkout It lists the following snippet: `uses: actions/checkout@v4` Almost everyone will just copy paste this snippet and call it a day. Most people don't think twice that v4 is a movable target that can be compromised. In case of npm/yarn deps, one would often do the same, and copy paste `yarn install foobar`, but then when installing, npm/yarn would create a lockfile and pin the version. Whereas there's no "installer" CLI for GH actions that would pin the version for you, you just copy-paste and git push. To make things better, ideally, the owners of actions would update the workflows which release a new version of the GH action, to make it update README snippet with the sha256 of the most recent release, so that it looks like `uses: actions/checkout@abcdef9876543210` # v4.5.6 Since GitHub doesn't promote good defaults, it's not surprising that third-party maintainers do the same.

xign 2y ago
I mean, I think there's a difference between trusting GitHub and trusting third parties. If I can't trust GitHub, then there's absolutely no point in hosting on GitHub or trusting anything in GitHub Actions to begin with. But yes I do think using tags is problematic. I think for one, GitHub should ban re-tagging. I can't think of a good reason for a maintainer to re-publish a tag to another commit without malicious intent. Otherwise they should provide a syntax to pin to both a tag and a commit, something like this: `uses: actions/checkout@v4.5.6@abcdef9876543210` The action should only work if both conditions are satisfied. This way you can still gain semantics version info (so things like dependabot can work to notify an update) but the commit is still pinned. --- I do have to say though, these are all just band-aids on top of the actual issue. If you are actually using a dependency that is compromised, someone is going to get screwed. Are you really going to read through the commit and the source code to scan for suspicious stuff? I guess if someone else got screwed before you did they may report it, but it's still fundamentally an issue here. The simple answer is "don't use untrustworthy repositories" but that is hard to guarantee. Only real solution is to use as few dependencies as possible.

0rzech 2y ago

Some people do actually pin versions, like me. For instance: - uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7 or - uses: subosito/flutter-action@f2c4f6686ca8e8d6e6d0f28410eeef506ed66aff # v2.18.0 It's a bit more manual work, but lepiej dmuchać na zimne (lit. it is better to blow on something cold), as the Polish proverb says.

brokenpip3 2y ago
>It's a bit more manual work after this incident, I started pinning all my github workflows with hashes, like other folks here I guess :D But I quickly got tired of doing it manually so I put together this [0] quick and dirty script to handle it for me. It just updates all workflow files in a repo and can be also used as a pre-commit hook to catch any unpinned steps in the future. It’s nothing fancy (leveraging ls-remote), but it’s saved me some time, so I figured I’d share in case it helps someone else :) [0] https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov-file#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks?tab=readme-ov...
- 0rzech 2y ago
  > github action dependency with the hash of the specific tag and a human readable tag that dependabot will keep/update in the future [1] Allowing bots to do that is going to make you vulnerable to such attacks anyway. [1] https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657bd43b5043994cf981b216374c15f6ef3/README.md#github-actions-hash https://github.com/brokenpip3/pre-commit-hooks/blob/f01df657...
matsemann 2y ago
You would still be exposed if you had renovate or dependabot make a PR where they update the hash for you, though. Here's a PR we got automatically created the other day: -uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3 +uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3 and this PR gets run with privileges since it's from a user with write permissions.
- 2y ago