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

281–290 of 317 posts

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

#281

Post by 3np »

rarkins wrote: post #177

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

So I follow steps 1-4 but don't see what triggered step 5, if they indeed just did an orphan commit outside of releases or main branch?

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

#282

Post by junon »

srvaroa wrote: post #247
rarkins wrote: post #177

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…

I theorized about this vulnerability a while back when I noticed new commits didn't disable automerging. This is an insane default from GH.

EDIT: seems GitHub has finally noticed (or started to care); just went to test this and auto merge has been seemingly disabled sitewide. Even though the setting is enabled, no option to automerge PRs shows up.

Seems I was right to worry!

EDIT2: We just tested this on GitLab's CI since they also have an auto-merge function and it appears they've done things correctly. Auto-merge enablement is only valid for the commit for which it was enabled; new pushes disable auto-merge. Much more sensible and secure.

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

#283

Post by wutwutwat »

arianvanp wrote: post #172
wutwutwat wrote: post #36

Earlier quoted context omitted.

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…

One problem with this is that actions can be Composite and call arbitrary other actions. So only if you use actions that themselves lock everything by commit for the actions they depend on you're safe.

You just described a supply chain, and the risks that come with them, which is something every dep management system is dealing with, rubygems, npm, etc

Again, it all comes down to your risk tolerance. There's a certain level of trust built into these systems.

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

#284

Post by wutwutwat »

chuckadams wrote: post #257
wutwutwat wrote: post #36

Earlier quoted context omitted.

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.

> Someone elsewhere suggested a lockfile

commit hashes are immutable, and your own commit history can serve as the lock file.

but if you're targeting a commit hash directly, it's already locked. Lock files are for mapping a version range to a real life version number. Lock files are useless if you pin the exact version for everything.

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

#285

Post by mgiladi »

We've recently released open-source tools that would have easily prevented this:

1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: https://github.com/apiiro/PRevent

2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevant CI/CD stages: https://github.com/apiiro/malicious-code-ruleset

3. For a better understanding of the detection, the malicious code falls precisely into the patterns presented in our research: https://apiiro.com/blog/guard-your-codebase-practical-steps-...

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

#286

Post by trallnag »

captn3m0 wrote: post #117
mceachen wrote: post #79

Earlier quoted context omitted.

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…

Sounds about right to me. We can use a few knowns about GitHub IAM to deduce a few things: 1. There are no deleted PRs or Issues on the repo (2461..2463 are all valid refs) 2. A legitimate `Renovate[Bot]` dep bump would have filed a PR. Last such PR was 5 days ago, and is presumably not the source for this. (I haven't gone through every dep change, but doesn't look like it). 3. That leaves us with the 0e58ed867 commi…

Renovate can be configured to update dependencies without raising a pull request.

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

#287

Post by ronjouch »

juliob wrote: post #280
ronjouch wrote: post #178

Earlier quoted context omitted.

Yeah, and thx for the link to the neat crx explorer. Close to what you do, I started writing my own addon to replace a couple addons whose featureset I use only partially. For example, when I use Chromium I want 1. to customize the New Tab page, and 2. to add a keyboard shortcut to pin/unpinTab. These two features are absolutely part of extensions, but in addition to the security risk I find them heavy (I don’t need…

You shouldn’t need an extension just to add a keyboard shortcut for a menu item. Doesn’t your OS let you map that? On macOS you can in Keyboard Settings

Indeed, one point for MacOS! I use GNOME.

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

#288

Post by chuckadams »

wutwutwat wrote: post #284
chuckadams wrote: post #257

Earlier quoted context omitted.

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.

> Someone elsewhere suggested a lockfile commit hashes are immutable, and your own commit history can serve as the lock file. but if you're targeting a commit hash directly, it's already locked. Lock files are for mapping a version range to a real life version number. Lock files are useless if you pin the exact version for everything.

Sure, it's just that the DX of getting that commit hash isn't terrific, so one might be more inclined to trust an auto-update bot to automatically update them instead. A lock file is more like TOFU on a tag. I'd also take a UI like a "bake" button and CLI flag that substituted the hashes automatically, but you just know people are going to build `--bake` right in to their automation.

Another solution would be to implement immutable tags in git itself, but git upstream has so far been hostile to the whole concept of immutability in any part of git.

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

#289

Post by varunsharma07 »

I’m Varun, CEO & Co-Founder of StepSecurity. StepSecurity detected and reported the tj-actions/changed-files compromise and has been actively helping the community recover from this incident.

To support you in understanding what happened and recovering swiftly, we’re hosting an Office Hour:

Date: March 17, 2025 Time: 10:00 AM Pacific Time (PT) Add to your calendar: https://www.addevent.com/event/Tf25207322

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

#290

Post by sieabahlpark »

rarkins wrote: post #177

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

[dead]
Post reply on HN