Live data from Hacker News

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

stepsecurity.io

251–260 of 317 posts

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

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

This is why I have begin to prefer languages with comprehensive, batteries-included standard libraries so that you need very few dependencies. Dep Management has become a full time headache nowadays with significant effort going into CVE analysis.

Instead of bloating the base language for this, a trusted entity could simply fork those libraries, vet them, and repackage into some "blessed lib" that people like you can use in peace. In fact, the level of trust needed to develop safe libraries is less than developing language features.

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

#252
post #51
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…

This isn't new - Thompson warned us 40 years ago (and I believe others before him) in his Reflections on Trusting Trust paper. It's something I've been thinking about lately because I was diving into a lot of discussion from the early 90s regarding safe execution of (what was, at the time, called) "mobile code" - code that a possibly untrustworthy client would send to have executed on a remote server. There's actuall…

Trusting Trust is not about this at all. It's about the compiler being compromised, and making it impossible to catch malicious code by inspecting the source code.

The problem here is that people don't even bother to check the source code and run it blindly.

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

#253
Due to the ongoing security incident involving the tj-actions/changed-files Action, we at StepSecurity have provided a secure, drop-in replacement: step-security/changed-files.

We strongly advise replacing all instances of tj-actions/changed-files in your workflows with our secure alternative: https://github.com/step-security/changed-files

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

#254
post #238

Earlier quoted context omitted.

I wasn't aware of the already existing SHA-1 collision support created by Github. It's very interesting read and AFAIK it seems that using SHA-1 collisions is not possible: https://github.blog/news-insights/company-news/sha-1-collisi... Is anyone aware of a git hook I could use to analyse my .github/workflows/*.yml files and replace git tags like "v4" with the current git commit hashes? I think this would make it muc…

That's the sort of hook you should be able to write yourself pretty quickly. So I threw your comment into o3-mini-high and it gave me a decent-looking solution. Decent but wrong, since it thought "current git commit" referred to the project repo, rather than the referenced dependency. Anyway here's the gist of a solution without any of the necessary checking that the files actually exist etc. #!/bin/sh for file in .g…

Thanks! Today I learned:

$ git ls-remote "https://github.com/$repo.git" "refs/tags/$tag"

Even though the grep and sed are not very readable this was very useful way to avoid yet another tool!

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

#255

Another reason why you should be getting software via distro, with searate maintainers taking care of it there rather than directly from the developers that can inject malware via the very next version you mindlessly pull in without checking. Also due to here being usually more than one distro, more people will look at the code & can spot the usptream getting rogue or getting compromised.

Adding MITM to your chain of trust doesn't make it more trustworthy, it adds an extra possible attacker.

Actually it does. The repo maintainer is on the user's side, so they are doing MITM on the attack vector. This makes it harder to get your malicious code in, because MITM might intercept it.

Yes now you have to trust the maintainer but that's sometimes easier.

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

#256
post #201

Hi, Renovate author/maintainer here. The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is: 1. An attacker had write access to the tj-actions/changed-files repo 2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate 3. Important: this spoofing of commits wasn't done to "trick"…

> 6. Some people had automerging of such updates enabled, but this is not Renovate's default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it's run as part of PR builds I'm not sure how this could exploited by just making a PR, unless you for some reason have secrets enabled for builds by unknown contributors, which obviously would be a mistake. Usually, o…

Neither Branch Protection nor the newer Rulesets allow to protect secrets from someone with push acces to the repo. From what I understand, only environment secrets provide this feature (and have the drawback that you can't share them among multiple repos in the same org without copying them everywhere, although you can script the copying with the github api)

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

#257

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

Someone elsewhere suggested a lockfile, which seems a pretty obvious solution in hindsight. I'm fine with commit hashes, but the UX is terrible and consists of pasting the action into into StepSecurity's thingie, when this is something that GH should have built in.

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

#258

The GitHub repo and org disappeared while I was poking around. Both https://github.com/tj-actions and https://github.com/tj-actions/changed-files return 404.

Is there a safe fork somewhere?

A colleague sent this: https://github.com/trmlabs/changed-files

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

#259

Hi, Renovate author/maintainer here. The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is: 1. An attacker had write access to the tj-actions/changed-files repo 2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate 3. Important: this spoofing of commits wasn't done to "trick"…

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

Tags can be signed, and the signature can be verified. It's about as easy as signing / verifying commits. One can even make signing tags as the default option when creating tags.

This won't help in this case though, because a legitimate bot was tricked into working with a rogue commit; a tricked bot could as well sign a tag with a legitimate key.

"Immutable tags" of course exist, they are commit hashes, but they are uninformative :(

Post reply on HN