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

Malicious code in the purescript NPM installer

harry.garrood.me

Post reply on HN
Print view View original

21–30 of 279 posts

Re: Malicious code in the purescript NPM installer

#21

Post by uponcoffee »

btown wrote: post #12
hn_throwaway_99 wrote: post #5

Earlier quoted context omitted.

I think the blog author is implying as much as he can, without directly accusing, that he believes that https://github.com/shinnn was responsible for the bad code, not a random hack.

To quote the article: "As far as we are aware, the only purpose of the malicious code was to sabotage the purescript npm installer to prevent it from running successfully... the purpose of this condition [in the code, hardcoded to include the word 'cli'] seems to be to ensure that the malicious code only runs when our installer is being used (and not @shinnn’s)." :hmm:

>>[[ 9 July, around 0100 UTC: @doolse identifies thatload-from-cwd-or-npm@3.0.2 is the cause. See purescript/npm-installer#12 (comment) @doolse opens an issue on the load-from-cwd-or-npm repo pointing out that the package is breaking the purescript npm installer (although at this stage, none of us spot that the code is malicious). This issue is later deleted by @shinnn. ]]

Hmm indeed. A hack is possible but the timeline of events is dubious.

Re: Malicious code in the purescript NPM installer

#22

Post by lonelappde »

hombre_fatal wrote: post #6

Another reminder of how annoying it is for a package system to have unqualified package names. Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`. This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better. You see all so…

There's nothing preventing whatever_purescript. Even if you have namespacing, anyone who owns a spot in it can sell or rent their spot to a malicious actor.

Re: Malicious code in the purescript NPM installer

#23

Post by ff_ »

sieabahlpark wrote: post #10

Well I guess it's good I didn't start using this after an article I saw yesterday about it.

The facts the article refers to happened two weeks ago and have since been resolved, taking further steps to reduce the chance of this happening again in the future (e.g. by vendoring a lot of code)

Re: Malicious code in the purescript NPM installer

#24

Post by geofft »

Fellshard wrote: post #20
McGlockenshire wrote: post #13

Earlier quoted context omitted.

Even PHP gets this right. It's not hard. It makes me wonder why npm hasn't already moved to namespaced package names.

Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe, and so seem to reinvent the wheel, rediscover the worst of software's history, and discard the most useful of software findings with shocking regularity. NPM tends to reinforce the worst of the JS world's tendencies.

Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does, so that doesn't seem to be the explanation here.

Re: Malicious code in the purescript NPM installer

#25

Post by pvg »

neilv wrote: post #18
hombre_fatal wrote: post #6

Another reminder of how annoying it is for a package system to have unqualified package names. Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`. This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better. You see all so…

Java got that part right in the 1990s, when it was the cool Web-savvy language. At the time, I especially liked how they piggybacked onto the existing DNS domain name control, avoiding having to create a new centralized registry to keep names unique. (Of course, more could be done beyond that, today.)

they piggybacked onto the existing DNS domain name control

It's a recommended and widely-followed voluntary naming scheme - it's not in any way connected to domain name control.

Re: Malicious code in the purescript NPM installer

#26

Post by luckylion »

johnchristopher wrote: post #11
braythwayt wrote: post #4

Earlier quoted context omitted.

I beg your pardon, but if I am using this library as part of a shipping piece of software-as-a-service, and I am in the middle of shipping a new feature when suddenly things mysteriously crash... If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. It's no different than a disgruntled person putti…

> If I later discover that the crash was put there deliberately, I am going to call that malice, and malice that has directly impacted a functioning business and its customers. Hey, it's open source party ! Where is your patch ? /s edit: oh, bummer. Not really open source. Still: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, etc. How are we supposed…

You touch on an interesting point there if the typical disclaimer is included: does that actually protect against willfully damaging code?

It's certainly (and reasonably so) very hard to hold a developer accountable for a bug in an open source library they published. But what if they put rm -rf / in the installer with the intent to delete the files of anybody running it? Does "you should've looked" really work there, or is there an assumption of good nature and malicious behavior voids the disclaimer?

Re: Malicious code in the purescript NPM installer

#27

Post by timothycrosley »

hombre_fatal wrote: post #6

Another reminder of how annoying it is for a package system to have unqualified package names. Having to ask someone to gift a `purescript` package shouldn't even be a thing. It should've been `@shinn/purescript` and the compiler developers just create their own `@whatever/purescript`. This is something Elm and many others got right. https://package.elm-lang.org/ It's just infinitely, obviously better. You see all so…

I don't actually feel like this solves anything, but instead just adds one more avenue for name hijacking. Now instead of trying to register an angular package first, I'll try to register a google namespace, or similar. If google is taken, I'll make an official_google, or g00gle etc.

Re: Malicious code in the purescript NPM installer

#28

Post by sieabahlpark »

ff_ wrote: post #23
sieabahlpark wrote: post #10

Well I guess it's good I didn't start using this after an article I saw yesterday about it.

The facts the article refers to happened two weeks ago and have since been resolved, taking further steps to reduce the chance of this happening again in the future (e.g. by vendoring a lot of code)

Well that's good

Re: Malicious code in the purescript NPM installer

#29

Post by jasonwatkinspdx »

bsamuels wrote: post #2

I wonder how bad will this cred-stuffing package authors problem will get before npm/other package managers flat out require 2FA for maintainers

I mean, do you really think some hacker compromised @shinnn's account, solely for the purpose of sabotaging a new installer that had only been published for 8 hours?

I mean, I'm all for benefit of the doubt and such, but it's pretty obvious what happened here.

Re: Malicious code in the purescript NPM installer

#30

Post by vbezhenar »

pvg wrote: post #25
neilv wrote: post #18

Earlier quoted context omitted.

Java got that part right in the 1990s, when it was the cool Web-savvy language. At the time, I especially liked how they piggybacked onto the existing DNS domain name control, avoiding having to create a new centralized registry to keep names unique. (Of course, more could be done beyond that, today.)

they piggybacked onto the existing DNS domain name control It's a recommended and widely-followed voluntary naming scheme - it's not in any way connected to domain name control.

But it's easy to connect to domain name control. Allow uploading to maven central only after domain verification. Java did not do that, AFAIK, but other languages can do that.
Post reply on HN