JavaScript registry NPM vulnerable to 'manifest confusion' abuse | Hacker News Reader

JavaScript registry NPM vulnerable to 'manifest confusion' abuse

theregister.com

15 pointsDotnaught11 comments

I like The Register, but perhaps the URL should be updated, since this is mostly blogspam wrapping the original source (which is linked from the article): https://blog.vlt.sh/blog/the-massive-hole-in-the-npm-ecosyst...

Thank you for this informative and readable link!

OG author here: any sharing/retweets of my original post are much appreciated.

ref. https://twitter.com/darcy/status/1673749748338008083?t=H-Iy1...

I actually did a POC 7 years ago about this - https://github.com/tanepiper/steal-ur-stuff

It was reported to npm at the time, but they chose to ignore it - https://github.com/npm/npm/issues/17724

Sorry if I'm misunderstanding, but how is this the same issue discussed in the article?

That postinstall and other scripts have been a problem for a long time - the PoC for example could be installed via npx, which would then run postinstall which executes another script to steal /etc/password data.

This is not a new problem, you just have another vector.

I came up with a free linter package to try solve it - but no one seemed interested, and here we are 7 later talking about where people are now offering paid services to mitigate it.

https://github.com/tanepiper/npm-lint

Nice tool, but I don't see how it would detect the issue described in the blog post, which is that the manifest uploaded to npm does not match the manifest inside the tarball. The package.json that's presented to npm is never actually downloaded into your node_modules.

The tool was for the toolchain work 7 years ago, maybe if it had continued I've have worked on a bunch of stuff around dependency checking (which I actually did write recently). Like I said I tried to speak up about it then and was shut down by several npm core people so I just moved on instead of spending the energy.

(Everyone seems so focused on the blog post and missing the fact since NPM was created you've been able to manipulate it's postinstall script to install malware - at any level, including npms failure to verify the manifest file)

Your reported issue is just about the fact that `npx` triggers lifecycle scripts, which is by design.

OP is about the fact that manifest contents of the same package version may differ between package contents and registry and looking at the registry is not sufficient to tell which lifecycle scripts will be triggered for a package.

The deeper issue however reflects the same problem regardless of different manifest contents - npm has no control over validation of scripts, or their execution.

The issue I repeated was just one vector of executing these script attacks, the attached PoC shows how easy it is to create a supply chain attack with npm (you focusing on the npx part is the red herring)

Npm have ignored it for years and now it's getting more common.

tldr; This issue allows an attacker to include a 'hidden dependency' in a package that won’t show up on the npm website, even though the CLI will actually install it.

The issue is caused by a disparity between a package's manifest and its tarball contents, which npm does not enforce are consistent. And unfortunately, a lot of data – such as the dependencies, install scripts, license, etc. – is duplicated between the package.json in the tarball and the metadata served by registry.npmjs.org. And every tool uses a different source of truth.

Socket (disclosure: my startup), I'm proud to say, has been using the correct manifest file - the package.json inside the tarball - for all security analysis, which aligns with the installation behavior of every major package manager. This means any attempt to exploit this technique would not have evaded Socket’s analysis. We wrote more about manifest confusion here: https://socket.dev/blog/manifest-confusion

Reply on news.ycombinator.com