GitHub supply chain attack spills secrets from 23,000 projects It's not such a happy Monday for defenders wiping the sleep from their eyes only to deal with the latest supply chain attack. StepSecurity disclosed a compromise of the popular GitHub Action tj-actions/changed-files, which works to detect file changes in open source projects, noting that more than 23,000 GitHub repositories …
The "delete this action and find an alternative" seems kind of dumb advice. The vulnerability has been found, fixed, dodgy commits cleaned up and steps have been taken to prevent it happening again. Arguably this repository/organization is now more secure and has a better security posture than before. By switching surely you're now potentially swapping to an action written by someone else that's less maintained?
I am using this action in a couple of places, but went through the pain of pinning all actions to the commit SHA so I feel slightly vindicated now.
I love a cheap shot at micros~1 as much as the next person, but to be fair, this wasn't their fault.
There's a third party marketplace for actions you can use in your GitHub workflows to save you reinventing the same wheels over and over again. It just so happened that one of those actions was compromised.
GitHub is yet another example of M$ taking something good (Git) and enshittfying it for public consumption. If your IT dept. understands Git and SSH you don't need insecure walled-up "actions" in the first place, or even a GitHub account. If not, Hahahahah!!!
Also, people should not have ANY sensitive information on there to leak - would you agree with that?
Any damage they suffer through using GitHub is therefore self-inflicted.
I have pinned usage of tj-actions to a versioned sha hash. Dependabot updates me with a PR if it changes.
The last PR was Feb 10 (long ago) to 45.0.7 with a subsequent PR once again at the weekend to a new hash.
Ostensibly I would not have been affected but I rotated keys anyway.
I’m not sure I understand how projects would have been affected because my usage model seems quite vanilla.
"I have pinned usage of tj-actions to a versioned sha hash"
Kudos for you. You are one of the few whom do not directly link their JS/other stuff being used - in their pages - to Google and the likes. Most devs do link their stuff without pinning and are susceptible to chain attacks.
I've asked the same thing before and got nothing serious in reply - how do you trust any code from some rando on the interwebs, whether it's Linux distros, Github packages, Nuget packages and all the rest? At least with something provided by Microsoft/IBM/HP et al, you know they vetted their staff before hiring them, or you know who to sue if it all goes really pear-shaped.
Your point is taken, but it doesn't address the basic problem of who is putting that software out there, how do you know who they are and if they can be trusted. You seem to think I can figure that out somehow for the millions of packages out there, but that shouldn't be my job, nor the job of everyone else out there to clear that hurdle. Just like everyone reads every EULA completely and understands it. Not.
Perhaps a better way of putting it would be that Microsoft/HP/IBM et al would suffer incredible reputational damage and loss of business ($$$) if they allowed someone to put something malicious into their packaged software. They are therefore far more likely to put significant resources and safeguards into their process, which is what I saw (from a distance) when I worked there a very long time ago.
And in this sort of scenario it wouldn't be me sueing Microsoft, it would be major corporations with an axe to grind, or governments threatening sanctions. I am certainly not delusional enough to try that myself.
Someone sneaking a package into github probably doesn't give a monkeys, specially if they're safely squirreled away in North Korea or Russia.
The org I work for is very switched on. Private repos are scanned for secrets constantly. We don’t use GitHub actions. Frequent and strict security training for all employees, however..,
It’s still going to be a busy day. I suspect there will be a mandatory credentials reset.
The bottom line is don’t store secrets in GitHub repos. Use a secrets manager as part of the deploy pipeline.
This wasn't really anything to do with storing secrets in the repository, if that was the case anyone could just clone a public repository and pick through it. Good advice nonetheless though.
GitHub provides safe secret storage, (it's all based on public key crypto if you peek under the hood), but at some point you have to provide those secrets to your pipeline(s), in the clear, unless every tool knows how to directly speak to your chosen secrets manager.
Normally what happens is any GitHub secrets used automatically install a filter such that any time that secret value is logged, it gets ***'d out, which can be mildly amusing if you're testing things and set the secret value to something fairly commonplace that occurs naturally in your logs, i.e. set a secret with a value of "test", anywhere "test" appears in your logs, even if it's nothing to do with that secret, it gets ***'d out.
Because secrets are write-only if you ever forget what you set the secret to, you can't just run an action that logs it because it will get masked out as above, but you can pipe the secret value through base64 or similar encoding and log that, the filters are not (yet) clever enough to catch that. You can then pick the encoded value out of the logs and decode it. This is basically what the attack was doing.
Git uses SHA-1 for hashing, not security. That is okay.
However, as soon as someone writes code to "get the code with this SHA hash from someone else's Git repo and run it", then the SHA is being used for security. It's the only thing authenticating that the code being run is what you intended to run. That's one of the options that GitHub provide.
Now, you might be happy with that level of security. Or you might not. Personally I would be a lot happier using SHA3-256, although even SHA256 would be an improvement.
That fantasy is covered by the AC post above. I suppose it is at least one level above "hit yourself with a hammer", but these days I can't claim to be surprised any more at weird dev practices.
We used to be specifically taught not to do that with shell scripts without reading them first . . .
I trust Linus to understand the implications, and there are reams of posts about this on the LKML going back to the early days of Git, for any historians here.
How much code does Linus actually look at (or amyone else you can name and actually trust), versus the swathes of code that gets lumped together in a distro, or randomly downloaded in some addon, just 'because'.
Ain't no million eyes on every element, let alone trustworthy eyes or even competent.
This post has been deleted by its author
This post has been deleted by its author
