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

31–40 of 317 posts

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

#31

Post by OptionOfT »

CaliforniaKarl wrote: post #21
jasonthorsness wrote: post #12

Earlier quoted context omitted.

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).

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

#32

Post by frenchtoast8 »

xyst wrote: post #27

A company I worked at went all in on GH too. The internal gh team probably going to do a fire drill this whole weekend and app teams forced to rotate all secrets and credentials. Fortunately don’t have to deal with that shit anymore

My day job is also in the middle of moving everything to Github Actions, so this is fun. But in my case, we aren't affected by this vulnerability because it could only be exploited by workflows with public logs, and currently my company only uses Github Actions for private repositories.

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

#33

Post by throwaway48476 »

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…

The solution for trusting dependencies is signed public builds and ML 'weirdness' detectors that require manual review.

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

#34

Post by xyst »

Pretty good timing on the attacker.

https://github.com/tj-actions/changed-files/tags?after=v35.9...

Most folks around the world signed off. B-squad probably left cleaning up remaining tasks or just fucking around with co-workers and pondering the weekend. Most GH actions run on a schedule (ie, backups of db, connecting to blob storage services).

Attacker(s) likely to extract plenty of secrets and exfil data before the alarms get triggered (if any) at companies.

The next data dumps are going to be wild.

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

#35

Post by cmckn »

dan_manges wrote: post #7

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

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

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

#36

Post by wutwutwat »

random17 wrote: post #26

I wish Github required some sort of immutability for actions by default as most package managers do, either by requiring reusable actions to be specified via commit hash or by preventing the code for a published tag to be changed. At the moment the convention is to only specify the tag, which is not only a security issue as we see here, but may also cause workflows to break if an action author updates the action.

You can target `some/action@commithash` already, that's up to you. You're also free to fork or clone each action you use, vet the code, and consume your fork in your workflows. You can also disable the use of third party actions at an org level, or approve them on a case-by-case basis.

This all depends on your threat model and risk tolerance, it's not so much a GitHub problem. There will always be bad code that exists, especially on the largest open source code hosting platform. You defend against it because that's more realistic than trying to eradicate it.

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

#37

Post by frenchtoast8 »

dboreham wrote: post #28

Good policy to fork all actions not owned by a reputable organization (e.g. github themselves).

You can combine this with a policy that blocks third party actions from being used across your organization. https://docs.github.com/en/organizations/managing-organizati...

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

#38

Post by mixologic »

dan_manges wrote: post #7

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

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

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

#39

Post by ashishb »

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…

> Can you really say you trust all of these?

We need better capabilities. E.g. when I run `fd`, `rg` or similar such tool, why should it have Internet access?

IMHO, just eliminating Internet access for all tools (e.g. in a power mode), might fix this.

The second problem is that we have merged CI and CD. The production/release tokens should ideally not be on the same system as the ones doing regular CI. More users need access to CI (especially in the public case) than CD. For example, a similar one from a few months back https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-inj...

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

#40

Post by bolognafairy »

throwaway48476 wrote: post #33
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…

The solution for trusting dependencies is signed public builds and ML 'weirdness' detectors that require manual review.

If this were “the solution”, then the many, many smart individuals and teams tasked with solving these problems throughout the software industry would’ve been out of work for some time now.

It’s obviously more complicated than that.

Signed public builds don’t inherently mean jack. It highly depends on the underlying trust model.

—

Malicious actor: “we want to buy your browser extension, and your signing credentials”.

Plugin author: “Well, OK”.

—

Malicious actor: hijacks npm package and signs new release with new credentials

The vast majority of dependent project authors: at best, see a “new releaser” warning from their tooling, which is far from unusual for many dependencies. ignores After all, what are they going to do?.

—

Hacker News, as usual, loves to pretend it has all the answers to life’s problems, and the issue is that nobody has listened to them.

Post reply on HN