Live data from Hacker News

GitLab discovers widespread NPM supply chain attack

about.gitlab.com

101–110 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#101
post #82

Earlier quoted context omitted.

There's an xckd for that :) The one with 12 competing standards going to 13 competing standards, or something like that.

Pretty sure Microsoft is exponentially bigger than 99% of the library authors out there, and add to that the giant communication channel that GitHub gives it over developers, so the analogy breaks pretty fast.

Or it's worse, because there's a good bunch of devs that don't trust MS by default?

Re: GitLab discovers widespread NPM supply chain attack

#102
About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “brew uninstall npm” instead, and eventually strung together an oldschool unix utilities pipeline with some awk thrown in. Probably the best decision of my life, in retrospect.

Re: GitLab discovers widespread NPM supply chain attack

#103

I'm a victim of this. In addition to concerns about npm, I'm now hesitant to use the GitHub CLI, which stores a highly privileged OAuth token in plain text in the HOME directory. After the attacker accesses it, they can do almost anything on behalf of me, for example, they turned many of my private repos to public.

this, this, this All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile. And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

This doesn't sound like a technical problem to me. Even my throw-away bash scripts call to `secret-tool lookup`, since that is actually easier than implementing your own configuration.

Also this is a complete non-issue on Unix(-like) systems, because everything is designed around passing small strings between programs. Getting a secret from another program is the same amount of code, as reading it from a text file, since everything is a file.

Re: GitLab discovers widespread NPM supply chain attack

#104

I have an friend that starts an project next month that will rely on npm. He is quite a noob and didn't code in ages. He will have almost no clue how to harden against this, he will probably not even notice if he becomes a victim until something really bad happens. Pretty sad.

At least make them run pnpm instead of npm, disabling post-install scripts. https://pnpm.io/supply-chain-security

Re: GitLab discovers widespread NPM supply chain attack

#105
post #42

Earlier quoted context omitted.

Larger attack surface (JS has been the #1 language on GitHub for years now) and more amateur developers (who are more likely to blindly install dependencies, not harden against dev attack vectors, etc).

Unfortunately, blindly installing dependencies at compile-time is something that many projects will do by default nowadays. It's not just "more amateur developers" who are at risk here. I've even seen "setup scripts" for projects that will use root (with your permission) to install software. Such scripts are less common now with containers, but unfortunately containers aren't everything.

> blindly installing dependencies at compile-time is something that many projects will do by default nowadays.

I consider this to be a sign that someone is still an amateur, and this is a reason to not use the software and quickly delete it.

If you need a dependency, you can call the OS package manager, or tell me to compile it myself. If you start a network connection, you are malware in my eyes.

Re: GitLab discovers widespread NPM supply chain attack

#106
post #20

Earlier quoted context omitted.

This was largely the reason I rejected "real name verification" ideas at GitHub after the xz attack. (Especially if they are state sponsored) it's not that hard for a dedicated actor (which xz certainly was) to get a quality stolen identity. The inevitable evolution of such a feature is a button on your repo saying" block all contributors from China, Russia, and N other countries". I personally think that's the antit…

That would be easily defeated by a VPN. The inevitable evolution would be some kind of in-person attestation of identity backed up with some kind of insurance on the contributor's work, and, well you're converging on the employer-employee relationship then.

So... GPG?

Re: GitLab discovers widespread NPM supply chain attack

#107

The credential harvesting aspect is what concerns me most for the average developer. If you've ever run `npm install` on an affected package, your environment variables, .npmrc tokens, and potentially other cached credentials may have been exfiltrated. The action item for anyone potentially affected: rotate your npm tokens, GitHub PATs, and any API keys that were in environment variables. And if you're like most deve…

To me, the worming aspect and taking developers data as hostages against infrastructure take down is most concerning.

Previously, you had isolated places to clean up a compromise and you were good to go again. This attack approaches the semi-distributed nature and attacks the ecosystem as a whole and i am affraid this approch will get more sophisticated in the future. It reminds me a little of malicious transactions written into a distributed ledger.

Re: GitLab discovers widespread NPM supply chain attack

#108

Lucky for us C programmers. Each distro provides its own trusted libc, and my code has no other dependencies. :)

Do you rewrite fundamental data structures over and over, like maps, of just not use them?

C (actually POSIX) has a hashmap implementation: https://man7.org/linux/man-pages/man3/hsearch.3.html

What it doesn't have is a hashmap type, but in C types are cheap and are created on an ad-hoc basis. As long as it corresponds to the correct interface, you can declare the type anyway you like.

Re: GitLab discovers widespread NPM supply chain attack

#109
post #60

Everyone is blaming npm but GitHub should be put on blast too for allowing the repos to be created and not quickly flagged. GitHub has a massive malware problem as it is and it doesn’t get enough attention.

I love! how Github, as a corporate company now owned by Microsoft, is directly tied to GoLang as the main repository of the vast majority of packages/dependencies. Imagine the number of things that can go wrong when they try to regulate or introduce restrictions for build workflows for the purpose of making some extra money... lol The original Java platform is a good example to think about.

"The original Java platform" had no package management though, that came with Maven and later Gradle, that have similar vectors for supply chain attacks (that is, nobody reviews anything before it's made available on package repositories).

And (to put on my Go defender hat), the Go ecosystem doesn't like having many dependencies, in part because of supply chain attack vectors and the fact that Node's ecosystem went a bit overboard with libraries.

Re: GitLab discovers widespread NPM supply chain attack

#110
post #68

Is there any reason to keep using postinstall scripts allowed instead of asking e.g. the user? Are they even needed in most cases?

If you ask the user "should I run this script" after installing, they will just hit yes every time. But also, a lot (I'm confident it's "most") of NPM install operations are done on a CI server, which need to run without human interaction.
Post reply on HN