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

141–150 of 317 posts

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

#141

Post by padjo »

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…

Years ago I saw that most browser extensions ask for the permission “can access all data on all websites” and thought yeah let’s not do that…

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

#142

Post by _flux »

hypeatei wrote: post #87
yencabulator wrote: post #84

Earlier quoted context omitted.

Pledge is for self-isolating, it helps with mistakes but not against intentional supply chain attacks.

How so? Obviously this is ineffective at the package level but if the thing spawning these processes, like the GitHub runners or Node itself added support to enter a "restricted" mode and pledged then that would help, no?

According to https://www.openbsd.org/papers/eurobsdcon2017-pledge.pdf pledge turns off upon execve. Surely it would be quite limiting for runners to use it.

As far as I see its purpose is mostly a mitigation/self-defence for vulnerabilities in C-based apps, so basically limiting what happens once the attacker has exploited a vulnerability. Maybe it has other uses.

It could be used defending against bugs in the Node runtime itself, as you say, but as I understand vulnerabilities in the Node runtime itself are quite rare, so more fine-grained limitations could be implemented within itself.

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

#143

Post by stockhorn »

Gigachad wrote: post #67
usef- wrote: post #22

Earlier quoted context omitted.

Yes. Same with browser plugins. I've heard multiple free-plugin authors say they're receiving regular offers to purchase their projects. I'm sure some must take up the offer.

I have long since stopped using any extension that doesn’t belong to an actual company (password managers for example). Even if they aren’t malware when you installed them, they will be after they get sold.

A bit off topic, but how is the bitwarden browser extension protected against supply-chain attacks (npm dependencies)?

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

#144

Post by werrett »

zahlman wrote: post #92
werrett wrote: post #77

Earlier quoted context omitted.

You can pin GitHub Actions to specific versions or specific commits. But note you can change version tags arbitrarily. In this specific case, the bad actor changes all of the version tags to point to their malicious commit: https://github.com/tj-actions/changed-files/tags So to avoid that you'd have to pin your GitHub Action to specific commits as outlined in this SO post: https://stackoverflow.com/a/78905195

> In this specific case, the bad actor changes all of the version tags to point to their malicious commit: https://github.com/tj-actions/changed-files/tags This required compromising the entire repository, yes? It can't be explained as the maintainer being tricked into merging something malicious?

Yes. It was probably a maintainer's creds being compromised.

The [malicious commit is masquerading as a commit from Renovate](https://github.com/tj-actions/changed-files/commit/0e58ed867...)((https://github.com/apps/renovate) but it's not a `verified` commit (and so it's trivial for a bad actor to masquerade as them).

https://stackoverflow.com/questions/67609381/why-do-all-my-g...

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

#145

Post by kalaksi »

harrisi wrote: post #41

It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub. I know they're auditable and you pin versions, but it's crazy to me that the recommended way to ssh to a server is to just give a random package from a random GitHub user your ssh keys, for example. This is especially problematic with the rise of LLMs, I think. It's the kind of common task which is annoying en…

So much this. I recently looked into using GitHub Actions but ended up using GitLab instead since it had official tools and good docs for my needs. My needs are simple. Even just little scripting would be better than having to use and audit some 3rd party repo with a lot more code and deps.

And if you're new, and the repo aptly named, you may not realize that the action is just some random repo

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

#147

Post by mnahkies »

ashishb wrote: post #39
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 nee…

I've found firejail to be a useful tool for this (https://github.com/netblue30/firejail), and additionally use opensnitch (https://github.com/evilsocket/opensnitch) to monitor for unexpected network requests.

For CI/CD using something like ArgoCD let's you avoid giving CI direct access to prod - it still needs write access to a git repo, and ideally some read access to Argo to check if deployment succeeded but it limits the surface area.

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

#148

Post by prmph »

To me the only solution is that we need a security in depth approach:

- Create a trusted packages program, and mark trusted packages with a prominent badge. Package authors can apply to join the program, which will involve a review of their package and any subsequent updates. Ensure trusted packages can only depend on other trusted packages.

- Implement a capabilities model for package managers. I hear Deno is better in that respect.

- Have the package manager back-end use AI to continually review the packages. If anything suspicious is found, flag it and investigate manually.

- Require all packages to be name-spaced

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

#149

Post by [deleted] »

captn3m0 wrote: post #118

Helpful update: The gist author has deleted the gist, so https://gist.githubusercontent.com/nikitastupin/30e525b776c4... now results in a 404, and stops the action from any further secrets being leaked. This means you're impacted only if you used the action, and had a build triggered in the last 6 hours or so.

[deleted]

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

#150

Post by [deleted] »

rognjen wrote: post #126
captn3m0 wrote: post #117

Earlier quoted context omitted.

Sounds about right to me. We can use a few knowns about GitHub IAM to deduce a few things: 1. There are no deleted PRs or Issues on the repo (2461..2463 are all valid refs) 2. A legitimate `Renovate[Bot]` dep bump would have filed a PR. Last such PR was 5 days ago, and is presumably not the source for this. (I haven't gone through every dep change, but doesn't look like it). 3. That leaves us with the 0e58ed867 commi…

> Update the tags in the parent repository to point to the SHA of the fork I don't think that's possible. Forks are a GitHub UI construct. There would be two .git dirs so for all intents and purposes they're two repos that don't know about each other. Locally you can't refer to a commit that's in a different dir...

[deleted]
Post reply on HN