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

171–180 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#171

Post by naikrovek »

febusravenga wrote: post #75
wonderfuly wrote: post #67

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.

> no way do do it correctly in MacOS

What? The MacOS Keychain is designed exactly for this. Every application that wants to access a given keychain entry triggers a prompt from the OS and you must enter your password to grant access.

Re: GitLab discovers widespread NPM supply chain attack

#172

Post by jwr »

qubex wrote: post #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 “bre…

I used to run npm only inside docker containers, and I've been regularly laughed at on these forums. I eventually gave up…

Re: GitLab discovers widespread NPM supply chain attack

#173

Post by tedivm »

silverwind wrote: post #156
broeng wrote: post #66

Earlier quoted context omitted.

Compared to the Java ecosystem, I think there's a couple of issues in the NPM ecosystem that makes the situation a lot worse: 1) The availability of the package post-install hook that can run any command after simply resolving and downloading a package[1]. That, combined with: 2) The culture with using version ranges for dependency resolution[2] means that any compromised package can just spread with ridiculous speed…

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

Re: GitLab discovers widespread NPM supply chain attack

#174

Post by duncanbeevers »

silverwind wrote: post #159
dtech wrote: post #36

Earlier quoted context omitted.

Npm has weak security boundaries. Basically any dependency can (used to?) run any script with the develop permissions on install. JVM and python package managers don't do this. Of course in all ecosystems once you actually run the code it can do whatever with the permissions of the executes program, but this is another hurdle.

Deno has tackled some of these issues with their permission system, but afaik it can only be applied to apps, not to dependencies. What we really need is a system to restrict packages in what they can do (for example, many packages don't need network access).

Lavamoat purports to do this. https://lavamoat.github.io/

There has been some promising prior research such as BreakApp attempting to mitigate unusual supply-chain compromises such as denial-of-service attacks targeting the CPU via pathological regexps or other logic-bomb-flavored payloads.

Re: GitLab discovers widespread NPM supply chain attack

#175

Post by dmitrygr »

john01dav wrote: post #73
dmitrygr wrote: post #32

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?

Often yes, specialized to the specific thing I am doing. Eg: for a JIT translator one often needs a combo hash-map + LRU, where each node is a member of both structures.

Re: GitLab discovers widespread NPM supply chain attack

#176

Post by hiccuphippo »

dawnerd wrote: 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.

Pushing the data to Github was a blessing in disguise. A friend wouldn't have noticed he got caught if it didn't create a repo on his account. It would have been worse if it silently sent the data to some random server.

Re: GitLab discovers widespread NPM supply chain attack

#177

Post by TeMPOraL »

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

Stupid question, but:

- If it's safe to "ignore scripts", why does this option exist in the first place?

- Otherwise, what kind of cascade breakage in dependencies you risk by suppressing part of their installation process?

Re: GitLab discovers widespread NPM supply chain attack

#178

Post by philipwhiuk »

qubex wrote: post #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 “bre…

The lesson surely though is 'don't use web-tech, aimed at solving browser incompatibility issues for local scripting'.

When you're running NPM tooling you're running libraries primarily built for those problems, hence the torrent of otherwise unnecessary complexity of polyfills, that happen to be running on a JS engine that doesn't get a browser attached to it.

Re: GitLab discovers widespread NPM supply chain attack

#179

Post by TeMPOraL »

Ferret7446 wrote: post #69
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…

> if you're like most developers and reused any of those passwords elsewhere Is this true? God I hope not, if developers don't even follow basic security practices then all hope is lost. I'd assume this is stating the obvious, but storing credentials in environment variables or files is a big no-no. Use a security key or at the very least an encrypted file, and never reuse any credential for anything.

> Is this true? God I hope not, if developers don't even follow basic security practices then all hope is lost.

"Basic security practices" is an ever expanding set of hoops to jump through, that if properly followed, stop all work in its tracks. Few are following them diligently, or at all, if given any choice.

Places that care about this - like actually care, because of contractual or regulatory reasons - don't even let you use the same machine for different projects or customers. I know someone who often has to carry 3+ laptops on them because of this.

Point being, there's a cost to all these "basic security practices", cost that security practitioners pretend doesn't exist, but in fact it does exist, and it's quite substantial. Until security world acknowledges this fact openly, they'll always be surprised by how people "stubbornly" don't follow "basic practices".

Re: GitLab discovers widespread NPM supply chain attack

#180

Post by hiccuphippo »

broeng wrote: post #66
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?

Compared to the Java ecosystem, I think there's a couple of issues in the NPM ecosystem that makes the situation a lot worse: 1) The availability of the package post-install hook that can run any command after simply resolving and downloading a package[1]. That, combined with: 2) The culture with using version ranges for dependency resolution[2] means that any compromised package can just spread with ridiculous speed…

Also badly named commands, `npm install` updates your packages to the latest version allowed by package.json and updates the lock file, `npm ci` is what people usually want to do: install the versions according to the lock file.

IMO, `ci` should be `install`, `install` should be `update`.

Plus the install command is reused to add dependencies, that should be a separate command.

Post reply on HN