Live data from Hacker News

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

stepsecurity.io

81–90 of 317 posts

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

#81
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.

I mean maybe! But only if you've removed all of the usage of this compromised `tj-actions/changedfiles` action, across all your repos and their branches.

Otherwise, if you continue to use it and it will run anytime there has been a push. Potentially on any branch, not just `main`! Depending on your GH config.

Unless you've blocked `tj-actions/changed-files` you're banking on the bad actor not coming back tonight and making malicious commit that exfils those secrets to pastebin.com.

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

#83

So this dumps env to stdout using some obfustucated code? And then relies on the fact logs are viewable publicly so the attacker can go scrape your secrets. If so, why did they use obfustucated code? Seems innocuous enough to load env into environment vars, and then later to dump all env vars as part of some debug routine. Eg. 'MYSQL env var not set, mysql integration will be unavailable. Current environment vars: ${…

[deleted]

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

#84
post #39

Earlier quoted context omitted.

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

OpenBSDs pledge[0] system call is aimed at helping with this. Although, it's more of a defense-in-depth measure on the maintainers part and not the user. > The pledge() system call forces the current process into a restricted-service operating mode. A few subsets are available, roughly described as computation, memory management, read-write operations on file descriptors, opening of files, networking (and notably sep…

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

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

#85
This is hilarious, the maven-lockfile project "Lockfiles for Maven. Pin your dependencies. Build with integrity" appears to have auto-merged a PR for the compromised action commit. So the real renovate bot immediately took the exfiltration commit from the fake renovate bot and started auto-merging it into other projects:

https://github.com/chains-project/maven-lockfile/pull/1111

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

#87

Earlier quoted context omitted.

OpenBSDs pledge[0] system call is aimed at helping with this. Although, it's more of a defense-in-depth measure on the maintainers part and not the user. > The pledge() system call forces the current process into a restricted-service operating mode. A few subsets are available, roughly described as computation, memory management, read-write operations on file descriptors, opening of files, networking (and notably sep…

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?

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

#88
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…

Yes, this...

I hope the irony is not completely lost on the fine folks at semgrep that the admittedly "overkill" suggested semgrep solution is exactly the type of pattern that leads to this sort of vulnerability: that of executing arbitrary code that is modifiable completely outside of one's own control.

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

#89

Not the first time this particular action has had a vulnerability, either. https://nvd.nist.gov/vuln/detail/CVE-2023-51664

I could have sworn that I've seen other GitHub Actions vulnerabilities that worked the same way, too. And/or HN submissions talking about this specific kind of vulnerability, the standard mitigation strategies, etc.

Feels like the same kind of problem as SQL injection, where everybody kinda knows about it and some people are actively aware and there are standard ways to avoid it but it still happens all the time anyway.

Might also be a good time to mention I'm really not a fan of YAML.

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

#90
post #61
post #44

Earlier quoted context omitted.

The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those can easily be changed (and often are, e.g. `v3` being updated from `v3.5.1` to `v3.5.2`).

You and someone else pointed this out. I only use GitHub-org actions, and I just thought that surely there would be a "one version to rule them all" type rule.. how else can you audit things? I've never seen anything recommending specifying a specific commit hash or anything for GitHub actions. It's always just v1, v2, etc.

OpenSSF scorecard flags dependencies (including GitHub actions) which aren’t pinned by hash

https://scorecard.dev/

https://github.com/ossf/scorecard/blob/main/docs/checks.md#p...

Post reply on HN