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.
Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
251–260 of 317 posts
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#252In 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…
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
#253We 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
#254Earlier 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…
$ 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
#255Another 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.
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
#256Hi, 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…
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#257I 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…
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#258The 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?
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#259Hi, 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…
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 :(