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

Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

stepsecurity.io

Post reply on HN
Print view View original

311–317 of 317 posts

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#311

Post by ronjouch »

jrockway wrote: post #135
mubou wrote: post #6

In recent years, it's started to feel like you can't trust third-party dependencies and extensions at all anymore. I no longer install npm packages that have more than a few transitive dependencies, and I've started to refrain from installing vscode or chrome extensions altogether. Time and time again, they either get hijacked and malicious code added, or the dev themselves suddenly decides to betray everyone's trust…

You can trust (in time), but you can't blindly upgrade. Vendor or choose to "lock" with a cryptographic hash over the files your build depends on. You then need to rebuild that trust when you upgrade (wait until everyone else does; read the diffs yourself). There is something to be said for the Go proverb "a little copying is better than a little dependency", as well. If you want a simple function from a complicated…

> the Go proverb "a little copying is better than a little dependency"

What a nice way to put it! Thanks for the mention and thanks for making me discover https://go-proverbs.github.io/ .

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#312

Post by 0rzech »

matsemann wrote: post #301
0rzech wrote: post #270

Earlier quoted context omitted.

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.

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.

From security standpoint, automating GitHub action hash updates defeats the purpose of pinning them in the first place.

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#313

Post by [deleted] »

xign wrote: post #310
matsemann wrote: post #301

Earlier quoted context omitted.

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.

I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise). Now, of course, if there are literally hundreds of dependencies…

[deleted]

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#314

Post by 0rzech »

brokenpip3 wrote: post #272
0rzech wrote: post #270

Earlier quoted context omitted.

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.

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

> 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/f01df657...

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#315

Post by matsemann »

xign wrote: post #310
matsemann wrote: post #301

Earlier quoted context omitted.

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.

I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise). Now, of course, if there are literally hundreds of dependencies…

Even if you don't automerge, the bots will often have elevated rights (it needs to be able to see your private repository, for instance), so it making a PR will run your build jobs, possibly with the updated version, and just by doing that expose your secrets even without committing to main.

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#316

Post by WhyNotHugo »

junon wrote: post #282
srvaroa wrote: post #247

Earlier quoted context omitted.

>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") an…

I theorized about this vulnerability a while back when I noticed new commits didn't disable automerging. This is an insane default from GH. EDIT: seems GitHub has finally noticed (or started to care); just went to test this and auto merge has been seemingly disabled sitewide. Even though the setting is enabled, no option to automerge PRs shows up. Seems I was right to worry! EDIT2: We just tested this on GitLab's CI…

GitLab has had this behaviour (disable auto-merge when new commits are pushed) since long before GitHub even had auto-merge.

It’s such an obvious attack vector, I’m pretty sure I tested GitLab soon after the feature initially rolled out.

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#317

Post by squiggleblaz »

HALtheWise wrote: post #274
deathanatos wrote: post #244

I've said this before, but in my mind the central problem in supply chain issues is this. Choose one: 1. You fix what version you're using to a fixed, immutable package. You receive no updates, no bug fixes, no security patches. 2. You follow a pointer to something like a API-compatible version, "latest" (#yolo) or ^5.0.0. You get bug fixes, security patches, but someone can push malicious updates. Security types, IM…

It seems like a 24hr delay for auto upgrades would mitigate a lot of this, maybe with some way that a trusted third-party could skip the delay for big-ticket zero day patches?

I think what we need is first and third party notifications about vulnerabilities in specific versions, and a culture of cherry-picking security fixes onto previous versions. (In many cases, the same patch will apply to a previous version without any real difficulty.) First and third party notifications both provide critical roles; I think we've leaned too heavily on first party notifications only, but that's a SPOF.
Post reply on HN