Indeed, Ghidra is available in many distros and is not hard to use for basic static analysis. The author took a massive risk and a thoughtful attacker will be ready to exploit this kind of panicked decision.
I have some intuition on why that would be bad, but could you go into more detail of what types of harm could come from this? Are there container escapes?
Maybe now is a good time to evaluate switching to other git ‘providers’? Microsoft has a long history of opt-in’ing users into bullshit like this in their other products.
Disabling actions is a big hammer. GitHub actions need to be individually enabled to work (which can be done only by an admin on the project). The problem here is a combination of a bunch of things. By default, GitHub actions will run only on the free runners for open source projects. There’s no limit to the total amount of these but you have a limit on the number that you can run concurrently. It’s useful to allow PRs to enable new actions because you can add new kinds of testing in the same PR that adds the feature that needs testing and it doesn’t hurt the project if someone abuses this, it only hurts GitHub (GitHub is paying for the VMs that run this).
The problem comes when you use a different kind of runner (ones that you pay for or that are hosted on infrastructure that you might care about) and you allow this configuration to be modified in the repo. GitHub provides tools for controlling this, but for the 99% of users that just use the free action runners it isn’t a problem.
Alpine? It even does not have the same libc? But ok…
Statically linked glibc would still require dynamic libraries for all the things that might use NSS.
Using alpine with its musl toolchain is a simple way to get fully static binaries.
Maybe I don’t understand the attack entirely, but why didn’t the attacker run this in an Action on a personal repo, which is just as free and would have stayed under the radar for much longer (i.e. no real person would look at it)?
You can set rules in most CI systems to filter by branch name, tag, event type, etc. to limit when workflows run. You can also often trigger CI manually, e.g. workflow_dispatch on GitHub Actions.
I have to admit, I did no slept peacefully last night. I was a bit anxious (for nothing) about having been infected while inspecting the prog cryptominer 😬 so I’m checking all the time my local system status with netstat and htop. If you, dear reader, are earning money from my computer CPU, please tell me 😁
It would be a mistake to interpret your words as anything other than information-free noise from an abuser.
https://lobste.rs/u/asymptotically, why did you give an invite to this person? (Post disowned by new user “Miner” who you invited 2 hours ago) It seems strange that you invited this abuser a few hours after this post showed up here, when you tend not to invite very many people to this community. Was this you?
Do not run malicious code in docker. This is an extremely risky decision to have made.
Indeed, Ghidra is available in many distros and is not hard to use for basic static analysis. The author took a massive risk and a thoughtful attacker will be ready to exploit this kind of panicked decision.
I have some intuition on why that would be bad, but could you go into more detail of what types of harm could come from this? Are there container escapes?
Container escapes are trivial.
Yeeaah, that’s a bit concerning. Just checked, ans sure enough, actions were automatically enabled on all of my repos.
Tossed together a small script to disable GitHub Actions on all repos you own, because I prefer to have ‘opt-in’ control over my repos: https://gist.github.com/cmonr/27d542eb0a33bde631c642707bb8bf92
Maybe now is a good time to evaluate switching to other git ‘providers’? Microsoft has a long history of opt-in’ing users into bullshit like this in their other products.
Disabling actions is a big hammer. GitHub actions need to be individually enabled to work (which can be done only by an admin on the project). The problem here is a combination of a bunch of things. By default, GitHub actions will run only on the free runners for open source projects. There’s no limit to the total amount of these but you have a limit on the number that you can run concurrently. It’s useful to allow PRs to enable new actions because you can add new kinds of testing in the same PR that adds the feature that needs testing and it doesn’t hurt the project if someone abuses this, it only hurts GitHub (GitHub is paying for the VMs that run this).
The problem comes when you use a different kind of runner (ones that you pay for or that are hosted on infrastructure that you might care about) and you allow this configuration to be modified in the repo. GitHub provides tools for controlling this, but for the 99% of users that just use the free action runners it isn’t a problem.
Statically linked glibc would still require dynamic libraries for all the things that might use NSS. Using alpine with its musl toolchain is a simple way to get fully static binaries.
Maybe I don’t understand the attack entirely, but why didn’t the attacker run this in an Action on a personal repo, which is just as free and would have stayed under the radar for much longer (i.e. no real person would look at it)?
Each GitHub account has a quota of free Actions minutes. I assume this attacker wanted to exceed the single-account quota.
(Disclosure: GitHub employee, not working on Actions though.)
Why are PRs counted towards the quota of the receiver instead of the submitter?
That’s a great idea if you wanted to provide “incentive” for projects to pay for upgrading.
Is there a limit For public repos as well? I thought it was only for private…
can queue up how many you want on free tier but only 20 run concurrently.
[Comment removed by author]
Very nefarious! I in general find these CI pipelines to be excessively wasteful. Is there a way to turn them on only when needed?
You can set rules in most CI systems to filter by branch name, tag, event type, etc. to limit when workflows run. You can also often trigger CI manually, e.g.
workflow_dispatchon GitHub Actions.Disclaimer: GitHub employee, but not on Actions.
Interesting to see an article about me :) — Can answer any questions, also sorry about the notification spam.
its just XMRig, no infection)
It would be a mistake to interpret your words as anything other than information-free noise from an abuser.
https://lobste.rs/u/asymptotically, why did you give an invite to this person? (Post disowned by new user “Miner” who you invited 2 hours ago) It seems strange that you invited this abuser a few hours after this post showed up here, when you tend not to invite very many people to this community. Was this you?
This person talks publicly about their mining on IRC. I found it very funny to see a post about them so I decided into invite them here to comment.