This code does more than leak environments. The go code pulls down arbitrary text and passes it to sh -c, example: https://github.com/zerops-io/zcli/commit/0396ee57bc0e5e0b123...
Malicious code added to 35k GitHub repos, leaking user environments
21–30 of 79 posts
Re: Malicious code added to 35k GitHub repos, leaking user environments
#22TL;DR: These are forks by unknown people containing malware. I see no indication in the linked thread of even a single successful compromise actually occurring, or malicious code making it into legitimate upstream projects.
Re: Malicious code added to 35k GitHub repos, leaking user environments
#23This is that thing where people can put anyone in as the commit author, thus impersonating the original creator right? Seems like the solution is "don't just copy random github urls into your code" ?
Correct. My suggestion for a solution is for github to add a "reject-unsigned" feature. Only allow commits signed by and to be pushed to github, under any projects/org.
They have something under Settings > SSH and GPG keys where you can enable Vigilant mode.
While that still allows pushing unsigned commits, it will flag them with a warning batch.
I had this on for a while, but unfortunately as some open source projects tend to rebase commits before pushing them, this was causing warnings to be shown (as the rebase breaks my signature), so I turned it off again as to not scare people when looking at the commit history of a project and seeing warnings after my contributions were merged in.
Re: Malicious code added to 35k GitHub repos, leaking user environments
#24note that it's 35,613 code results, not 35k repos
and 13K of the search results come from this org
Re: Malicious code added to 35k GitHub repos, leaking user environments
#25This is that thing where people can put anyone in as the commit author, thus impersonating the original creator right? Seems like the solution is "don't just copy random github urls into your code" ?
This is also a problem for enterprises. I’ve seen commits from root, ec2-user, etc: GitHub knows who’s pushing a commit even if git doesn’t, and it’s maddening that at least for enterprise accounts they don’t carry that identity into the metadata.
That would change the commit hash, at least if you want it to survive a clone of the repo. Of you'd store it externally so that it would only be able to be shown in the webui then it's of limited use, but maybe better than nothing.
Re: Malicious code added to 35k GitHub repos, leaking user environments
#26> So far found in projects including: crypto, golang, python, js, bash, docker, k8s Huh? What does that mean?
It appears what is infected are forks of those repos but not the originals.
Re: Malicious code added to 35k GitHub repos, leaking user environments
#27Earlier quoted context omitted.
Correct. My suggestion for a solution is for github to add a "reject-unsigned" feature. Only allow commits signed by and to be pushed to github, under any projects/org.
They have something under Settings > SSH and GPG keys where you can enable Vigilant mode. While that still allows pushing unsigned commits, it will flag them with a warning batch. I had this on for a while, but unfortunately as some open source projects tend to rebase commits before pushing them, this was causing warnings to be shown (as the rebase breaks my signature), so I turned it off again as to not scare people…
Good to know, I was not aware.
The squash/rebase issue is definitely problematic, though a tree of signatures could be appended to each commit. Now... this does break how commits are currently signed.
Re: Malicious code added to 35k GitHub repos, leaking user environments
#28> So far found in projects including: crypto, golang, python, js, bash, docker, k8s Huh? What does that mean?
The author is being obtuse. They mean that clones have been made of those projects that include malicious code.
It's like if I make a copy of the New York Times website but replace the cover image with nudity and put it on a different URL and someone tweets "omg NYT has nudity on the front page" and clarifies, vaguely, 10 tweets down that it was actually not the real NYT but a clone.
I'm not convinced that the author is spinning it this way on purpose (ie for maximum emotional effect / retweets / internet points) or if it just comes from being too close to the subject matter, but it's pretty misleading either way.
Re: Malicious code added to 35k GitHub repos, leaking user environments
#29Earlier quoted context omitted.
This is also a problem for enterprises. I’ve seen commits from root, ec2-user, etc: GitHub knows who’s pushing a commit even if git doesn’t, and it’s maddening that at least for enterprise accounts they don’t carry that identity into the metadata.
That would change the commit hash, at least if you want it to survive a clone of the repo. Of you'd store it externally so that it would only be able to be shown in the webui then it's of limited use, but maybe better than nothing.
I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. GitHub could then make use of this data to populate whatever.
(Not sure if such a field already exists in the commit blob)
Re: Malicious code added to 35k GitHub repos, leaking user environments
#30Earlier quoted context omitted.
Correct. My suggestion for a solution is for github to add a "reject-unsigned" feature. Only allow commits signed by and to be pushed to github, under any projects/org.
Let me ask a few questions about this scheme: 1. What happens when someone needs to resolve a merge conflict involving your commit? Let's say I maintain a fork of an open source repo to add some feature, and I periodically merge back in upstream changes... that necessarily involves resolving conflicts. By default, git retains author ownership, and now the commit is unsigned, but it's really your work. What do we do?…
And now we’re on the fast track to adopt a blockchain as a tamper evident mechanism.