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

71–80 of 317 posts

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

#71

Post by password4321 »

Terr_ wrote: post #48
cmckn wrote: post #35

Earlier quoted context omitted.

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

> commit hashes There is some latent concern that most git installations use SHA-1 hashes, as opposed to SHA-256. [0] Also the trick of creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands. [0] https://git-scm.com/docs/hash-function-transition

creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands

TIL; yikes! (and thanks)

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

#72

Post by werrett »

mceachen wrote: post #20
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…

GitHub actions supports version numbers, version ranges, and even commit hashes.

Only commit hashes are safe. In this case the bad actor changed all of the version tags to point to their malicious commit. See https://github.com/tj-actions/changed-files/tags

All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed867...

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

#73

Post by hypeatei »

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…

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 separate, DNS resolution). In general, these modes were selected by studying the operation of many programs using libc and other such interfaces, and setting promises or execpromises.

[0]: https://man.openbsd.org/pledge.2

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

#74

Post by nextts »

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…

Also don't het GH actions to do anything other than build and upload artifacts somewhere. Ideally a write only role. Network level security too no open internet.

Use a seperate system for deployments. That system must be hygienic.

This isn't foolproof but would make secrets dumping not too useful. Obviously an attack could still inject crap into your artefact. But you have more time and they need to target you. A general purpose exploit probably won't hurt as much.

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

#75

Post by puffybuf »

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…

Stealing crypto is so lucrative. So there is a huge 'market' for this stuff now that wasn't there before. Security is more important now than ever. I started sandboxing Emacs and python because I can't trust all the packages.

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

#76

Post by werrett »

londons_explore wrote: post #65

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: ${…

No idea. But they didn't do a great job -- they broke the action, which caused build failures that people were going to notice.

The malicious commit only landed at 09:57 PDT today (March 14) in one specific action (out of a number that is quite popular). Maybe they were planning on coming back and doing proper exfil?

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

#77

Post by werrett »

edoceo wrote: post #57

Noob question: is it possible to version lock these things? Could one "vendor" these tools into a fork and use that in the pipeline? Maybe it's one of those possible but crazy endeavour?

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

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

#78

Post by ashishb »

CamJN wrote: post #46
ashishb wrote: 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…

You also need to block write access, so they can’t encrypt all your files with an embedded public key. And read access so they can’t use a timing side channel to read a sensitive file and pass that info to another process with internet privileges to report the secret info back to the bad guy. You get the picture, I’m sure.

> You also need to block write access, so they can’t encrypt all your files with an embedded public key. And read access so they can’t use a timing side channel to read a sensitive file and pass that info to another process with internet privileges to report the secret info back to the bad guy. You get the picture, I’m sure.

Indeed.

One can think of a few broad capabilities that will drastically reduce the attack surface.

1. Read-only access vs read-write 2. Access to only current directory and its sub-directories 3. Configurable Internet access

Docker mostly gets it right. I wish there was an easy way to run commands under Docker.

E.g.

If I am running `fd`

1. Mount current read-only directory to Docker without Internet access (and without access to local network or other processes) 2. Run `fd` 3. Print the results 4. Destroy the container

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

#79

Post by mceachen »

londons_explore wrote: post #65

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: ${…

Presumably the cracker:

1. spoofed an account whose PRs were auto-merged (renovate[bot]) 2. found that `index.js` was marked as binary, and knew that GitHub is "helpful" (for the exploit), and hides diffs in the PR for that file by default 3. shoved the chunk of base64 wayyyy down the commit, so the maintainer had review fatigue by the time they scrolled. Having "memdump.py" in the commit in plaintext would certainly highlight the exploit more than the b64 string.

Post reply on HN