Live data from Hacker News

Over 100k Infected Repos Found on GitHub

apiiro.com

161–170 of 187 posts

Re: Over 100k Infected Repos Found on GitHub

#161

Github is failing the same way usenet failed: everybody could post stuff to usenet just like everybody can create a github repository and there is nothing that sets an official repository apart from a spammers repository. When Amazon has "the everything store" as main strategic goal, they get hit by "90% of everything is junk". So they end up being a store of mostly junk. Github should figure out if their product is…

> or it is "I can trust this code". what might be better would be some kind of trust layer built into package managers so they (optionally) only allow verified repos to be installed

There are countless of solutions that try to do this, both official and non official, both at package and repository level, npm from NodeJS comes with a security audit tool for example, and most code hosting solutions nowadays have at least a SAST tool built in, but expecting more from free services it's a bit of pipe dream.

Obviously it's hard to make a one-size-fits-all solutions, bottom line is that if you use third party code for anything serious you have to do your due diligence from a security pov, a vulnerability assessment at the bare minimum.

Lots of big companies are in fact maintaining their own versions of whole package ecosystems just to manually address any security concern, which is a crazy effort.

Re: Over 100k Infected Repos Found on GitHub

#162

Earlier quoted context omitted.

Strong disagree. It’s not GitHub’s job to tell you what’s good or bad. Only the user of the code can do that because it’s context specific. “I can trust this code” is a fantasy that won’t happen. Don’t trust code, test it.

This seems like the “don’t use seat belts, drive safely” argument. Trust mechanisms in GitHub/etc can’t solve the whole problem, for sure. But some automated safety mechanisms at scale can reduce the risk for those who don’t follow perfect security practices, which has value to the world at large. Very few of us have the capacity to do even cursory validation for every update to every dependency of every bit of softw…

I’m not saying don’t scan code for vulnerabilities, I’m saying GitHub shouldn’t be the place that the scanning happens. A good place would be where the code is getting compiled /executed.

Re: Over 100k Infected Repos Found on GitHub

#163

Wonder if the whole curl + sudo shell script installer thing is going to come to an end any time soon? aka the whole "just run 'curl https://somesite/install.sh ' | sudo sh" to install our software Seems like it'd go very hand in hand with this infected stuff mentioned in the article.

It’s 0% worse than “add and trust our repository for your distro”, or “download this .deb/.rpm/installer”, or (worst of all) “do one of the above, but trusting a 3rd party who packaged this program for you, rather than the publisher”, which are the realistic alternatives.

Re: Over 100k Infected Repos Found on GitHub

#164

Earlier quoted context omitted.

This seems like the “don’t use seat belts, drive safely” argument. Trust mechanisms in GitHub/etc can’t solve the whole problem, for sure. But some automated safety mechanisms at scale can reduce the risk for those who don’t follow perfect security practices, which has value to the world at large. Very few of us have the capacity to do even cursory validation for every update to every dependency of every bit of softw…

I’m not saying don’t scan code for vulnerabilities, I’m saying GitHub shouldn’t be the place that the scanning happens. A good place would be where the code is getting compiled /executed.

That’s simply not possible. How do define a vulnerability? That’s all context dependent. It could be something as subtle as skipping an auth check if a magic string is part of the payload.

The main benefit of reusing software packages is that you don’t want to spend the effort of writing/reviewing all the internals of the component.

At some point, to trust an abstraction blindly, you need to instead follow reputation. Who has authority to say what is reputable or not is the difficult dilemma.

As seen with CVE authorities lately, it’s not easy. As much as they undermine their own authority by declaring everything as a CVE, vice versa, declaring every org in GitHub as “Verified” may eventually be easy for scammers to get as well.

Back in the days, just having an SSL certificate on your web site was a big stamp of trust. Now everybody has it and it doesn’t mean anything.

Re: Over 100k Infected Repos Found on GitHub

#165

In the good old days you could check the MD5 checksums of mostly everything you downloaded. But then you had to trust the website that published the checksums themselves.

That says absolutely nothing if the page serving the expected md5 sum is also compromised.

With HTTPS, everything is already checked in transit, so you don’t need to verify it again.

On top of that, with git, all the revisions are inherently verified as sha1 hashes.

In either case, what’s inside may still be malicious if you end up on a typosquatted repo.

Re: Over 100k Infected Repos Found on GitHub

#166
post #32

Earlier quoted context omitted.

> If you are a dev today, you should probably have at least thee firmly separated environments for work, hobby and personal stuff. I hate to call it out, but, isn’t that table stakes? Blending work and personal environments should be an obvious no. Are employers out there ok with this?

Big employers (at least the ones I know) aren't regarding work, I guess with smaller ones it maybe is, especially with BYOD? I think the issue probably isn't uncommon for freelancers/contractors too. Hobby and personal stuff I think a lot of people mix, I don't use the machine where I do bank/tax/etc stuff for hobby work, but I'm not sure that's common.

[deleted]

Re: Over 100k Infected Repos Found on GitHub

#167

I've noticed these too by randomly stumbling over similar repos. I usually don't run code from random repos, but now I have reached a point where I spin up a sandbox vm even when I trust the repo and the owners. If you are a dev today, you should probably have at least thee firmly separated environments for work, hobby and personal stuff.

> If you are a dev today, you should probably have at least thee firmly separated environments for work, hobby and personal stuff. I hate to call it out, but, isn’t that table stakes? Blending work and personal environments should be an obvious no. Are employers out there ok with this?

[dead]

Re: Over 100k Infected Repos Found on GitHub

#168
post #127
post #51

Earlier quoted context omitted.

instead the downloaded malicious code runs in prod. maybe, if you are lucky, it does something strange in CI and you can catch it. the only real solution is a reputation system (like https://github.com/crev-dev/cargo-crev ), which of course is unfortunately barely used

Any equivalent for non-Rust projects? I see git-crev is abandoned...

unfortunately the Rust version seems abandoned too :(

Re: Over 100k Infected Repos Found on GitHub

#169

Earlier quoted context omitted.

I'm less worried about backdoors accidentally appearing in LLM output and more worried about backdoors being placed into LLM output by 3 letter agencies. Maybe not today, but certainly in a few years time.

That seems pretty risky and easy to catch. The point of these LLMs is to produce code, we know they aren’t very reliable about it, so you have to check the code. So, it is more likely to get inspected than a random GitHub project, right? It also seems dangerous in the sense that… if there’s a type of prompt that is likely to create infected code, our intelligence agencies would, I guess, want it to hit our adversarie…

I agree that it's more likely to be inspected but I think the vast majority of developers aren't inspecting the code rigorously enough (including me, but I don't use LLMs for development) to catch non-obvious bugs, see for example the "Underhanded C contest" [0]

As you've pointed out, this vector would give them near surgical precision and insight into their target's code & systems, rather than casting a wide net with a vulnerable library on Github. They could use a model trained on "underhanded" code or even selectively overwrite parts of the responses with hand-crafted vulnerabilities while only targeting select organizations.

It makes me wonder what the business model of OpenAI and their peers is going to be over the long term. I can't imagine large corporations using "LLM as a service" indefinitely with the risk of IP theft and "bug injection".

[0] https://en.wikipedia.org/wiki/Underhanded_C_Contest

Re: Over 100k Infected Repos Found on GitHub

#170

Stupid question here -- whats the most efficient way to evaluate for vulnerabilities (i.e. remove the low level risk like 95% of the cases)? Is it trust the package manager or is there another quick way?

I’d love to be surprised, but I think there isn’t any way to evaluate for vulnerabilities other than read all the code (fairly carefully). I don’t think the ecosystem is set up to make it easy.

That's wrong because even coders can't write code without vulnerabilities inside their own software...

You probably instead should use a throwaway computer (or VM if you trust them), and not do anything personal on that computer, and then burn it.

Post reply on HN