Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious code added to 35k GitHub repos, leaking user environments

twitter.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Malicious code added to 35k GitHub repos, leaking user environments

#41

Post by baliex »

skrebbel wrote: post #28
jwilk wrote: post #12

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

Riiight, that makes a LOT more sense. This would have been HUGE if the actual repos were infected and it wasn’t even at the top here at HN. I was very worried for a minute there, your comment has calmed me right down. Thank you!

Re: Malicious code added to 35k GitHub repos, leaking user environments

#42

Post by ache7 »

raggi wrote: post #35
ache7 wrote: post #31

Earlier quoted context omitted.

Here is a commit with malicious code from a Microsoft employee: https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...

That commit was rewritten from https://github.com/Logicalis/asn1/commit/d60463189a563e49f19... which was signed, but is not in the fork.

Damn, github should show some big visible warning about this.

Re: Malicious code added to 35k GitHub repos, leaking user environments

#43

Post by xrisk »

Karellen wrote: post #36
xrisk wrote: post #29

Earlier quoted context omitted.

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)

> I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. That's not how git works.

I’m somewhat familiar with how git works. In my understanding, a commit is just a blob combining the commit information and a tree blob, hashing them together to create a commit id.

This design doesn’t preclude the usage of additional information in the commit blob that isn’t used to compute the hash.

(Think for example how file access times do not affect its hash)

Re: Malicious code added to 35k GitHub repos, leaking user environments

#44

Post by 3np »

ache7 wrote: post #31
3np wrote: post #22

TL;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.

Here is a commit with malicious code from a Microsoft employee: https://github.com/promonlogicalis/asn1/commit/7bdca06d0edf8...

As long as the commit is not signed (marked green), that means nothing.

Re: Malicious code added to 35k GitHub repos, leaking user environments

#45

Post by formerly_proven »

xrisk wrote: post #43
Karellen wrote: post #36

Earlier quoted context omitted.

> I feel the commit data could be extended to include some metadata that isn’t used to compute the hash. That's not how git works.

I’m somewhat familiar with how git works. In my understanding, a commit is just a blob combining the commit information and a tree blob, hashing them together to create a commit id. This design doesn’t preclude the usage of additional information in the commit blob that isn’t used to compute the hash. (Think for example how file access times do not affect its hash)

Git is a content-addressed object store, the address of any stored object is the hash of the object itself. So you actually can't stuff extra data into an object and not change its ID; this auxiliary data would need to go in a separate store indexed by object ID or a similar solution. The reason why file access times don't affect git hashes is because git does not store them.

Re: Malicious code added to 35k GitHub repos, leaking user environments

#46

Post by laserlight »

stevelacy wrote: post #5
muppetman wrote: post #3

How would code like this make it into so many repos? People accepting pull requests and not properly reviewing them? Or is there something even worse about this attack?

Many of the repos I found were clones of valid projects with same names under new orgs and new users. For instance, this projects is valid: https://github.com/scala-network/GUI-miner and it's infected clone: https://github.com/stellitecoin/gui-miner GPG signed commits by the legitimate users do not contain the malware

Considering that only clones are affected, your original tweet is downright wrong. None of the listed projects (python, js, bash, docker, k8s) are affected. Anybody can fork a repository to introduce malware.

Re: Malicious code added to 35k GitHub repos, leaking user environments

#47

Post by hgomersall »

TheDong wrote: post #18
stevelacy wrote: post #8

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

We've adopted this policy internally. It largely requires using the proper git workflow, rather than (in our case) gitlab's GUI flow, though we make an exception for a simple merge (I think it's verifiable that no code is added).

The check is that commits at the point of merge have a valid signature. Historical commits are part of the history and as such cannot be changed without an additional commit (with a valid signature). Previous unsigned commits are deemed trusted at the point you begin signing and checking.

Squash merge breaks stuff and shouldn't be used. To complete things, the restricted set of operations exposed through the GUI should sign using gitlab's or github's key (or some accepted bot key we've set), with the check happening on the input commits, but AFAICT that's not supported yet.

Re: Malicious code added to 35k GitHub repos, leaking user environments

#48

Post by oefrha »

What a garbage clickbait thread. From scary words like "attack", "infected", etc. you would think projects are compromised. But nothing is compromised. From wayyyyy down in the thread:

> The attacker creates FAKE orgs/repos and pushes clones of LEGIT projects to github.

Yeah, anyone can push anything to their own GitHub accounts/orgs, including malware. We know that.

Save yourself some time. Flagged.

Re: Malicious code added to 35k GitHub repos, leaking user environments

#49

Post by nicce »

jhugo wrote: post #39
rvz wrote: post #6

Oh dear. This is a gigantic disaster. If lots of software released today haven't been pinning their versions on release (especially Electron apps) or signing their commits if they are open-source, then this is a chaotic supply chain attack waiting to happen and is more worse than I thought. But really it is yet, another reason to avoid GitHub entirely and just self-host using GitLab or Gitea.

You may have misunderstood (understandably, because the tweets seem to be deliberately misleading). These are malicious commits in forks of repositories. There is no supply chain attack unless you make a habit of taking random forks of popular projects from GitHub and inserting them into your supply chain.

> There is no supply chain attack

Actually yes, this is all about supply chain attacks. Typosquatting is one of the most common methods. It goes under this category.

Post reply on HN