Live data from Hacker News

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

stepsecurity.io

221–230 of 317 posts

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

#221

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…

Tags are a git concept, not a GitHub concept. Tags provide human-readable names to commits. They're intended to be changeable, to allow things like a "latest" tag pointing to the latest release. Tags aren't versions, commit hashes are.

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

#222
post #210

Disclaimer: 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.

Thank you, cyrnel, for the feedback! We are trying our best to help serve the community. Now, we have separate recovery steps for general users and our enterprise customers.

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

#223
post #95

I’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

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

#224

Earlier 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.

Crime is lower than the 80s and 90s. It has been declining since 2023.

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

#225
post #95

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

Well, broaden your horizon a bit from an irrelevant example of a "library" of a few lines to a real one a of few thousand lines, then you might know. Also those same people also write insecure code before they retire. Experienced people write security bugs all the time.

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

#226
post #50
post #41

It'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.

I think a big part of the problem is the way one typically "installs" a GH action: by copy-pasting something from README of the action.

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

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

In the era of the key fob it's pretty automatic to lock the car every time. Some cars even literally do it for you. I hardly think of this, let alone get not great feelings about it.

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

#228

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

I get a lot or usability from having one single operating system.

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
It seems pretty awful that the de-facto way to use GitHub Actions is using git tags which are not immutable. For example to checkout code [1]:

- 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

#230

Earlier 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.

I don't think that's exactly what happened here: the compromise created new tags but generally the tag consumption relies on semantic versioning

In other words: you specify version 44, the attacker creates 44.1, you're still hosed.

Post reply on HN