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

231–240 of 279 posts

Re: Malicious code in the purescript NPM installer

#231

Post by fock »

inimino wrote: post #214
fock wrote: post #184

Earlier quoted context omitted.

Tell me, why one needs packages such as this except for personal (and ultimately npm) marketing: https://github.com/sindresorhus/shebang-regex - the whole thing smells

You're being downvoted because that is mean-spirited, but the reason we needed these packages is to find out what the right size of package is. We now have a lower bound.

I'm not sure what's mean-spirited about the simple statement that the size/complexity of the npm-eco-system arises only from personal/corporate business-decisions.

But thanks for telling me anyways ;)

Re: Malicious code in the purescript NPM installer

#232

Post by dcbadacd »

braythwayt wrote: post #224
yawaramin wrote: post #95

Earlier quoted context omitted.

> just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability. Open source software is almost always distributed with a license that explicitly disavows any such warranty or liability. This is pretty widely understood...

Just because you put it in a license, doesn't mean it will hold up in court. Example: I distribute a flashlight app. It contains an obfuscated bitcoin miner and a MITM that collects your login credentials. My license does not mention ether of these things, but it does say there is no warranty or liability. What do you think will happen if I am sued in court and/or charged with a crime?

What if the dev just publishes an update that removes the flashlight functionality? It isn't malware, it just doesn't work. I don't think you could sue the dev and win.

Re: Malicious code in the purescript NPM installer

#233

Post by allover »

kkapelon wrote: post #217
allover wrote: post #33

Earlier quoted context omitted.

> Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe Do you have any evidence to back up this statement, compared to developers in other languages? Or is this just business-as-usual JS bashing?

I cannot talk for all other languages but at least in Java 1)All packages that are published can never be unpublished or re-released from a different contributor 2)Packages are namespaced 3)Nobody downloads packages directly from the internet. You always use a proxy which in most companies has security scans. 4)There are no "local packages" (like the node_modules dir), so it is impossible for the checked out source c…

1) Same applies for npm (granted, this was only fixed after the left-pad incident, and npm was not the only language's registry to have that issue).

2) As mentioned elsewhere in this thread, npm supports namespaced packages, but they are not mandatory. There are other major languages' registries in same situation.

3) Can you back up 'nobody'. I would suspect a lot of companies don't use a proxy. Some JS teams also use an internal proxy for npm, but it is obviously additional infrastructure to setup/maintain which has a cost.

4) Never heard anyone raise this as a problem before.

> Not directly related to the incident of the original post, but I was mindblown when I realized that you can unpublish npm packages

You can't, with the exception of a 72 hour window, to allow for accidental publishing [1].

[1] https://www.npmjs.com/policies/unpublish

Re: Malicious code in the purescript NPM installer

#234

Post by jeltz »

rjmunro wrote: post #222
runeks wrote: post #177

The work “exploit” is used several times but none of the code seems to exploit anything. Also, “malicious code” usually has a different meaning than something that intentionally makes the program crash during the installation process.

I feel like this is only part of a wider attack - like by causing this not to download, it meant that users do some other action which opens them up to the real attack.

Nah, it was probably a childish old maintainer who decided to sabotage it.

Re: Malicious code in the purescript NPM installer

#235

Post by inimino »

iamleppert wrote: post #87
jasonhansel wrote: post #82

Earlier quoted context omitted.

...wow. I literally did not believe that until I clicked the link. JavaScript has gone too far.

The problem is clearly due to vanity metrics like number of packages motivating people to publish an insane number of useless packages to fluff their contributions.

That is not clear.

Re: Malicious code in the purescript NPM installer

#236

Post by davnicwil »

littlestymaar wrote: post #228
davnicwil wrote: post #219

Earlier quoted context omitted.

> pkg upgrade @person-a/some-package "You're on the latest version 1.2.3 of @package-a/some-package, however @person-a has officially transferred ownership of some-package to @person-b and there is a newer version 1.2.4 available at @person-b/some-package. If you'd like to upgrade, please update your dependency to @person-b/some-package"

That's the mechanism, I was asking about the benefit of namespace in that case. With this kind of ownership transfers you lose all the alleged security benefit of namespaces.

I think we're asking the same thing, or I've not explained well. I'm saying when ownership transfers, it'd be good to keep all the existing version history on the original namespace, exactly so you're not forced to update all your dependencies in case you don't need to upgrade and/or don't want the updates of the new owner.

Re: Malicious code in the purescript NPM installer

#237

Post by kkapelon »

allover wrote: post #233
kkapelon wrote: post #217

Earlier quoted context omitted.

I cannot talk for all other languages but at least in Java 1)All packages that are published can never be unpublished or re-released from a different contributor 2)Packages are namespaced 3)Nobody downloads packages directly from the internet. You always use a proxy which in most companies has security scans. 4)There are no "local packages" (like the node_modules dir), so it is impossible for the checked out source c…

1) Same applies for npm (granted, this was only fixed after the left-pad incident, and npm was not the only language's registry to have that issue). 2) As mentioned elsewhere in this thread, npm supports namespaced packages, but they are not mandatory. There are other major languages' registries in same situation. 3) Can you back up 'nobody'. I would suspect a lot of companies don't use a proxy. Some JS teams also us…

1) The fact that an incident actually forced something that Maven registry did since inception, doesn't actually reinfornce the original argument? (that JS developers did not look at what other languages were doing already)

2) Again, whoever thought that namespaces should be optional instead of required "doesn't seem to be aware of the rest of the software universe". Who took this decision? Why?

3) Do a survey on your own. Ask Java developers you know if they use Artifactory/Nexus in their job and note down the percentage. Then ask the same question to JS teams

4) Just because something hasn't been exploited yet, doesn't mean it shouldn't be fixed. By that definition if left-pad hadn't happened would you say that (unpublishing) packages has not been raised as a problem yet?

Re: Malicious code in the purescript NPM installer

#238

Post by inimino »

rwbcxrz wrote: post #137
na85 wrote: post #91

Earlier quoted context omitted.

It's an ecosystem full of reinventing the wheel. The most popular library, lodash, includes a reimplementation of a foreach loop for Pete's sake, for reasons passing understanding since it's part of the ecma spec. JavaScript is just amateur hour, and these things are going to keep happening. It's pathological.

Which foreach are you talking about? Array.prototype.forEach, for...in loops, for...of loops? The first only works with arrays and array-like objects. The second works on objects and arrays, but it iterates over all enumerable properties, so you don't want really want to use it for arrays. It's also made a lot less useful because it only iterates over properties, not keys. The third finally provides some sanity, but…

> Array.prototype.forEach

Yes, this one. If the object is an Array. According to whatever test they are using for that.

Lodash includes a reimplementation of Array.prototype.forEach because mistakes were made. It also works on other objects because other mistakes were made.

We all make mistakes. But just because there is a reason for something does not mean there is a good reason.

Re: Malicious code in the purescript NPM installer

#239

Post by Operyl »

JulianMorrison wrote: post #204
Operyl wrote: post #47

Earlier quoted context omitted.

No at that point they'd be saying "zomg NPM has a terrible bug that allowed the hacker to bypass my 2FA!" If someone is trying to redirect blame they'll always find some way to do so.

The problem is not liars, the problem is being unable to prove they were lying. With 2FA, the logs would prove it.

Unfortunately, based on preexisting cases it really doesn't make much of a difference, the liars will still deflect the blame and the logs will always be "wrong".

Re: Malicious code in the purescript NPM installer

#240

Post by arkh »

hu3 wrote: post #191
fock wrote: post #187

Earlier quoted context omitted.

well, the rate-map at least includes a function: https://github.com/sindresorhus/shebang-regex

A dependency for /^#!(.*)/; With 8.6 mil downloads and 71 dependents... https://www.npmjs.com/package/shebang-regex

I love the useless tests : https://github.com/sindresorhus/shebang-regex/blob/1cb5d4aee...

You could replace the regexp with something matching everything and they would still pass.

Post reply on HN