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

GitLab discovers widespread NPM supply chain attack

about.gitlab.com

Post reply on HN
Print view View original

191–200 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#191

Post by rafterydj »

nyrikki wrote: post #184
naikrovek wrote: post #168

Earlier quoted context omitted.

Here I go again: Plan9 had per-process namespaces in 1995. The namespace for any process could be manipulated to see (or not see) any parts of the machine that you wanted or needed. I really wish people had paid more attention to that operating system.

The tooling for that exists today in Linux, and it is fairly easy to use with podman etc. K8s choices clouds that a little, but for vscode completions as an example, I have a pod, that systemd launches on request that starts it. I have nginx receive the socket from systemd, and it communicates to llama.cpp through a socket on a shared volume. As nginx inherits the socket from systemd it does have internet access eith…

This sounds very interesting to me. I'd read through that blog post, as I'm working on expanding my K8s skills - as you say knowledge is very scattered!

Re: GitLab discovers widespread NPM supply chain attack

#192

Post by vedhant »

thepasswordapp wrote: post #31

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…

Even with periodoc rotation of credentials, attacker gets enough time to do sufficient damage. Imo, the best way to solve would be to not handle any sort of credentials at all at the application layer! If at all the application must only handle only very short lived tokens. Let there be a sidecar (for example) that does the actual credential injection.

Re: GitLab discovers widespread NPM supply chain attack

#193

Post by hiccuphippo »

TeMPOraL wrote: post #181
serial_dev wrote: post #62

Earlier quoted context omitted.

They pulled a little sneaky on ya, mentioning GitLab security features available to GitLab users in a GitLab Security blog post with GitLab logos everywhere. Call me a conspiracy theorist, but I start to think these people might be affiliated with GitLab.

It's more like, you don't know where honest technical evaluation ends, and an ad starts.

It's all an ad.

Re: GitLab discovers widespread NPM supply chain attack

#194

Post by loginatnine »

newsoftheday wrote: post #190

As a Java dev, seems like only a matter of time before Maven Nexus repo attacks become commonplace.

Send them a request to have Trusted publishers support at central-support (at) sonatype.com

I did that a couple of weeks ago and received an acknowledgment "Another request on Trusted Publishing option. Assigning to Product for review and further action." so this is a bit encouraging.

At least Maven dependencies don't execute scripts on install, but Maven plugins could have a big blast radius.

Re: GitLab discovers widespread NPM supply chain attack

#195

Post by jonhohle »

newsoftheday wrote: post #190

As a Java dev, seems like only a matter of time before Maven Nexus repo attacks become commonplace.

Over a decade ago at Amazon, all third party dependencies needed to be manually imported. On the one hand, it makes importing new versions or packages slow. On the other hand, there is a very explicit intention and log of every external change that made it into internal projects.

At my previous company, I implemented staged dependencies with artifactory so that production could never get packages that had never gone through CR, or staging environments first. They just were never replicated. That eliminated fuzzy dependency matches that showed up for the first time in production (something that did happen). Because dev to production was about 1 week, it also afforded time to identify packages before they had a chance to be deployed. Obviously it was less robust than manually importing.

Maybe self-hosted package caches support these features now, but 6-7 years ago, that was all manual work.

Re: GitLab discovers widespread NPM supply chain attack

#196

Post by jMyles »

philipwhiuk wrote: post #148
efortis wrote: post #100

Mitigate this attack vector by adding: ignore-scripts=true to your .npmrc https://blog.uxtly.com/getting-rid-of-npm-scripts

Or use pnpm

To delay updates, you mean?

I'm curious though: how do you avoid being stuck on the _vulnerable_ versions, delaying updates?

Re: GitLab discovers widespread NPM supply chain attack

#197

Post by SAI_Peregrinus »

tedivm wrote: post #173
silverwind wrote: post #156

Earlier quoted context omitted.

> The culture with using version ranges for dependency resolution Yep, auto-updating dependencies are the main culprit why malware can spread so fast. I strongly recommend the use `save-exact` in npm and only update your dependencies when you actually need to.

This advice leaves you vulnerable to log4j style vulnerabilities that get discovered though. The answer is a balance. Use Dependabot to keep dependencies up to date, but configure a dependency cooldown so you don't end up installing anything too new. A seven day cooldown would keep you from being vulnerable to these types of attacks.

Cooldowns only work if enough people don't use cooldowns (or don't use cooldowns longer than yours) for attacks to get noticed.

Re: GitLab discovers widespread NPM supply chain attack

#198

Post by homebrewer »

jMyles wrote: post #196
philipwhiuk wrote: post #148

Earlier quoted context omitted.

Or use pnpm

To delay updates, you mean? I'm curious though: how do you avoid being stuck on the _vulnerable_ versions, delaying updates?

pnpm disables all install scripts by default and makes it trivial to whitelist the few you need. It's usually just one or two, or sometimes zero, depending on the project. Even without malware, most postinstall scripts are used for spam and analytics, and running them makes your life worse.

npm should have died long ago, I don't know why it's still being used.

Re: GitLab discovers widespread NPM supply chain attack

#199

Post by sgammon »

wiradikusuma wrote: post #28

Does anyone know why NPM seems to be the only attractive target? Python and Java are very popular, but I haven't heard anything in those ecosystems for a while. Is it because something inherently "weak" about NPM, or simply because, like Windows or JavaScript, everyone uses it?

NPM lets you upload literally anything, without approval

Re: GitLab discovers widespread NPM supply chain attack

#200

Post by hrimfaxi »

sakisv wrote: post #123
mcny wrote: post #86

Earlier quoted context omitted.

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices. I feel like we are barking up the wrong tree here. The plain text token…

The way I solve the plain text problem is through a combination of direnv[1] and pass[2]. For a given project, I have a `./creds` directory which is managed with pass and it contains all the access tokens and api keys that are relevant for that project, one per file, for example, `./creds/cloudflare/api_token`. Pass encrypts all these files via gpg, for which I use a key stored on a Yubikey. Next to the `./creds` dir…

At least with direnv your exports are removed when you leave the directory.
Post reply on HN