Live data from Hacker News

Malicious code in the purescript NPM installer

harry.garrood.me

61–70 of 279 posts

Re: Malicious code in the purescript NPM installer

#61

Earlier quoted context omitted.

Imo your solution is just a band aid. The real solution is having a distribution of packages which are maintained and suppervised by a group of people. Like the linux distribution maintainers or the group that develops the language. Community contribuited packages should be declared "install at own risk" like in archlinux aur. All this is already solved. But people want to reinvent the wheel and ride the user generat…

That comes at a cost of lots of volunteer hours. I’m not sure if it would scale to NPM’s massive size.

npm's size is not independent of its curation strategy.

This can be construed as a good or a bad thing.

Re: Malicious code in the purescript NPM installer

#62

Earlier quoted context omitted.

While people give reasonable counter-arguments here to your point, it gets me thinking - I wonder if we could find a truly benign form of "malicious code" that "good guys" could use to find attack vectors before the "bad guys" do. Perhaps there could be a website set up to get pinged by "malicious" installers? Perhaps it displays stats of some sort? It could turn into a friendly game.

I actually built something like this a few months ago. I called it “OSSassin” (like the game[1]) so devs could sign up & get a unique ID/url to ping with the idea that everyone participating would then try to secretly, and not maliciously, “assassinate” the packages that have agreed to participate by sneaking in code to ping their endpoint. Just as a fun/friendly game to help identify potential vulnerabilities. It ha…

That sounds like a really fun gamification of an aspect of security research that maybe doesn't get much practical exploration.

I'm not sure, though, how the game would distinguish between vulnerable code pinging the endpoint, as opposed to a player simulating a successful attack by performing the ping themselves.

I feel like the attacker should be able to provide a link to a package on a software repo somewhere and the game should download the package and check for some unique "Player 123456 attacked this package" string.

This reminds me of a similar game someone created where they challenged people to add a certain string to any repo that the challenge creator maintained. An ingenious social engineer then pointed out that the rules of this game weren't in an easy to find place, so the challenge creator added a page to their blog, which was under version control... Game over. Unfortunately I can't remember any detail that would allow me to find a citation for this story.

Re: Malicious code in the purescript NPM installer

#63
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?

Primarily, I end up basing this off of the types of libraries being developed for Javascript, and what kinds of articles and thought leaders JS developers tout as innovative.

So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the

> vast majority of JS developers don't seem to be aware of the rest of the software universe

Forgive me if I dismiss this as business-as-usual JS bashing

Re: Malicious code in the purescript NPM installer

#64

Earlier quoted context omitted.

You are not a lawyer, because if you were, you would be aware that there is case law establishing that just because you don't charge for it, doesn't mean you aren't providing an implied warranty and aren't taking implied liability. There is absolutely zero chance that you can put malware into an open source project, give it away, and then when sued, stand up and say, "It was free, what do people expect?" You can call…

I don't know how you believe laws work or what you hope to discuss but the reality is that in the case of software, laws offer deterrence and recourse to any malicious actions. It's absolutely stupid to take a repository by an anonymous person, execute it and hope it's not malicious or doesn't have any bugs. Not to mention there's nothing obliging that a piece of software has to be bug free, maintained - go and now d…

You are arguinng a strawman. We are not discussing bugs or maintenance, we are discussing a person acting maliciously. Furthermore, you are talking about people being "stupid," which has no place in a discussion of whether a person giving away code has an obligation to not act maliciously.

Never in the history of the courts has a defendant's lawyer gotten up on his hind legs and intoned, "But your honour, the plaintiff was stupid," and had the case summarily dismissed.

Naturally, one can make arguments about what precautions the user of some software ought to reasonably be expected to perform to avoid harm.

I agree it may be prudent to assume that every maintainer is malicious and sits up all night trying to think of ways to put malware in your compiler, but I do not agree that this is going to be an effective defence in a court of law if you actually put malware in a piece of software that you give away.

Now please excuse me, I am about to audit every last line of code in Unix. I have no more time for exchanging pleasantries with you.

Re: Malicious code in the purescript NPM installer

#65

Earlier quoted context omitted.

Primarily, I end up basing this off of the types of libraries being developed for Javascript, and what kinds of articles and thought leaders JS developers tout as innovative.

So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the > vast majority of JS developers don't seem to be aware of the rest of the software universe Forgive me if I dismiss this as business-as-usual JS bashing

There is a difference between arbitrary bashing and giving concrete points of concern. I would hope such criticism would not be dismissed out of hand.

Re: Malicious code in the purescript NPM installer

#66
post #54

Earlier quoted context omitted.

Please list the group of people you trust to manage 1,037,274 packages.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

> but those 18K do a lot more than NPM

This is so hilariously wrong it's actually shocking it was written?

Re: Malicious code in the purescript NPM installer

#67
Part of the problem is the bounty for attacking NPM packages is high. You get a high profile exploit and lots of people talking about it, or you can even get some of your evil JS code running on thousands of sites on the back end or the front end.

Compounded by the fact there is no decent base class library for JS like you'd get for .NET [0]. Want to do anything you could do by default with .NET BCL? Like open a url, save a file (with nice api) or parse some XML?

Then npm i ... it is. And hope it doesn't pull in an exploit.

As a mitigation I recommend people consider writing their own code (NIH) for simple stuff not npm i all the things.

[0] I'm comparing to .NET but same could be said of Java/Python/Ruby etc.

Re: Malicious code in the purescript NPM installer

#68
post #54

Earlier quoted context omitted.

I trust these people to manage software packages: https://nm.debian.org/public/people/dm_all They “only” manage ~18K packages, but those 18K do a lot more than NPM: https://people.debian.org/~corsac/ perhaps number of packages is the wrong metric.

> but those 18K do a lot more than NPM This is so hilariously wrong it's actually shocking it was written?

[deleted]

Re: Malicious code in the purescript NPM installer

#69
post #37

Earlier quoted context omitted.

> That's just shifting the trust to a different (smaller) group of people. Practically speaking, shifting trust from a large, anonymous group of people, to a small group of people who are known and trusted by the community is a pretty good solution.

Please list the group of people you trust to manage 1,037,274 packages.

What do you propose should be done?

Re: Malicious code in the purescript NPM installer

#70
post #41
post #16

Before "tree shaking" I stored all npm modules in SCM and reviwed all updates as I had to commit after "npm update". I also put ton of files in .ignore as 90% of files in some packages are not required. I also used to include npm modules in distribution/deployment. So my request to npm is to add an option in the main package.json to disable tree shaking.

I evaluated wordpress plugins this way, a good way to check if something strange had crept in. By the ignored files do you mean non-code?

I think they mean code - just remove all files that your program doesn't touch. With something like JS, this should be doable in cases because of the way libraries tend to be designed.

The equivalent in a compiled language would be to strip unused symbols from the binary.

Post reply on HN