News for hackers. Stuff that matters.
Re:Understand filesystem takeover vulnerabilities in NPM Jav... by Normal_gaussian on Wednesday January 08, 2020 @12:10AM (#21988546)
First:

One package can attack by declaring a malicious executable (bin) with the same name as one from a package that you would intentionally use.

Second:

If the malicious package is installed globally, it is injected into your regular PATH, and can similarly "hijack" regular commands.

-

At first I read tfa and said "and? Thats what I expect it to do". Then I noted:

* for a given package installation, a dependencies dependencies bins are available. This is generally counter intuitive.

* conflicting bin entries do not generate warnings or errors.

On a personal note: - I dont install node modules globally. Wrt development it should stay in repo, and I'm not a fan of managing system utilities from anywhere other than my distros package manager.. largely because its a PITA (I'm looking at you Python). - I cant think of any reason why non top level dependencies should have their bin files exposed. That is madness. - if it was just top level files, this would be a meh - I should get a conflict warning but I (or my cocontributors) deliberately installed those packages, so im not too bothered there.

Re:Understand filesystem takeover vulnerabilities in NPM Jav... by latchkey on Wednesday January 08, 2020 @12:32AM (#21988637)
I personally don't ever install globally either. But I do have './node_modules/.bin' in my PATH because well... I'm lazy.

If two packages try to install the same filename in that directory, I would want a full stop failure so that I can work it out myself. I'm honestly a bit surprised this isn't already the case.

Re:Understand filesystem takeover vulnerabilities in NPM Jav... by ergothus on Wednesday January 08, 2020 @12:46AM (#21988691)
I did that in the past, but now I can run "npx WHATEVER"

The only problem is that npx ALSO defaults to installing things, which is ridiculous.