Wow that's scary, they updated tons of tags to an offending random commit. With the way repositories are included in automation and the fact that this adjusted the tags of older versions (so not requiring an upgrade) this sort of attack can have a huge impact very quickly :(. Maybe GitHub should have some kind of security setting a repo owner can make that locks-down things like old tags so after a certain time they…
Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
221–230 of 317 posts
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#222Disclaimer: I am a co-founder of StepSecurity. StepSecurity Harden-Runner detected this security incident by continuously monitoring outbound network calls from GitHub Actions workflows and generating a baseline of expected behaviors. When the compromised tj-actions/changed-files Action was executed, Harden-Runner flagged it due to an unexpected endpoint appearing in the network traffic—an anomaly that deviated from…
The advertising in this article is making it actively difficult to figure out how to remediate this issue. The "recovery steps" section just says "start our 14 day free trial". The security industry tolerates self-promotion only to the extent that the threat research benefits everyone.
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#223I’ve been saying for a while that there aren’t supply chain problems when the supply chain is the problem. I’m getting to the point where I feel that library use at all should be frowned upon, unless it is your own library, with obvious exceptions for the most widely used things like encryption and authentication. None of these things are particularly difficult, people just don’t want to do them “oh noes my velocity”
And writing your library should be frowned upon because you can easily add a major security vulnerability with your own two hands
People write the trusted, secure code, and people retire from that work, and new people need to come in and do the work. Inexperienced people are going to be writing code no matter what.
So, you are either saying that no one should write new libraries because a major security vulnerability could be introduced by their hands, or you are saying that all libraries should be written by hands which will not introduce a major security vulnerability, and neither of those is at all feasible.
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#224Earlier quoted context omitted.
This is the death of fun. Like when you had to use SSL for buying things online. Adding SSL was not bad, don't get me wrong. It's good that it's the default now. However. At one point it was sorta risky, and then it became required. Like when your city becomes crime ridden enough that you have to lock your car when you go into the grocery store. Yeah you probably should have been locking it the whole time. what would…
Just you wait. Here in America when your city becomes crime ridden enough you start leaving it unlocked again.
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#225Earlier quoted context omitted.
And writing your library should be frowned upon because you can easily add a major security vulnerability with your own two hands
If my library is left-padding a string with spaces, I don’t know how that could possibly introduce a major security vulnerability at all. People write the trusted, secure code, and people retire from that work, and new people need to come in and do the work. Inexperienced people are going to be writing code no matter what. So, you are either saying that no one should write new libraries because a major security vulne…
What I'm saying is if you imagine a world where there is so much time to be wasted rewriting the same library a thousand times, you could try to imagine spending a small share of that time hardening the supply chain
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#226It'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…
People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.
Let's have a look at a random official GH provided action:
https://github.com/actions/checkout
It lists the following snippet:
`uses: actions/checkout@v4`
Almost everyone will just copy paste this snippet and call it a day. Most people don't think twice that v4 is a movable target that can be compromised.
In case of npm/yarn deps, one would often do the same, and copy paste `yarn install foobar`, but then when installing, npm/yarn would create a lockfile and pin the version. Whereas there's no "installer" CLI for GH actions that would pin the version for you, you just copy-paste and git push.
To make things better, ideally, the owners of actions would update the workflows which release a new version of the GH action, to make it update README snippet with the sha256 of the most recent release, so that it looks like
`uses: actions/checkout@abcdef9876543210` # v4.5.6
Since GitHub doesn't promote good defaults, it's not surprising that third-party maintainers do the same.
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#227In 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 the death of fun. Like when you had to use SSL for buying things online. Adding SSL was not bad, don't get me wrong. It's good that it's the default now. However. At one point it was sorta risky, and then it became required. Like when your city becomes crime ridden enough that you have to lock your car when you go into the grocery store. Yeah you probably should have been locking it the whole time. what would…
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#228Earlier quoted context omitted.
https://www.qubes-os.org/ is the extension of this.
I’m not sure I can recommend Qubes entirely due to the usability aspect. I’ve used Qubes several times for a week at a time over the last few years. It’s gotten better, but they really need someone to look at the user experience of it all for it to be a compelling option. I’m regularly questioning myself if what I’m doing is making it less secure because I don’t understand exactly everything Qubes is doing. I know ho…
Sure it’s less secure than full isolation, but full isolation is a real pain.
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#229- uses: actions/checkout@v4
Github does advise people to harden their actions by referring to git commit hashes [2] but Github currently only supports SHA-1 as hashing algorithm. Creating collisions with this hashing algo will be more and more affordable and I'm afraid that we will see attacks using the hash collisions during my lifetime.
I wish that they will add support for SHA-256 soon and wrote product feedback regarding it here: https://github.com/orgs/community/discussions/154056
If this resonates with you please go and give it a thumbs up :)
[1]: https://github.com/actions/checkout?tab=readme-ov-file#usage
[2]: https://docs.github.com/en/actions/security-for-github-actio...
Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos
#230Earlier quoted context omitted.
GitHub actions supports version numbers, version ranges, and even commit hashes.
The version numbers aren't immutable, so an attacker can just update the versions to point to the compromised code, which is what happened here. Commit hashes are a great idea, but you still need to be careful: lots of people use bots like Renovate to update your pinned hashes whenever a new version is published, which runs into the same problem.
In other words: you specify version 44, the attacker creates 44.1, you're still hosed.