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

271–279 of 279 posts

Re: Malicious code in the purescript NPM installer

#271

Post by yawaramin »

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?

You're talking about an app. I'm talking about open source software freely posted online. Let's apply some common sense here. What you said:

> 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.

Now what will happen if you take this library author to court? Let's ask some basic questions that the court might touch on:

* What was the harm caused by the software breakage? You were unable to ship new versions of your software to customers, resulting in reduced revenues

* What general arrangement or expectation did you have with the library author? None, the library author distributed the library as open source and explicitly disavowed (in writing) any obligations to the library's users

* What specific arrangement did you have with the library author? None, you don't know the author personally and you never transacted with them, offered them any compensation, or any other kind of business arrangement to provide you with the library

* What evidence do you have that the author acted maliciously? Almost none–they acted erratically but did try to offer a reasonable non-malicious explanation

I don't think any court in its right mind would find any substance in this case. If it did, every Tom, Dick, and Harry would start crawling out of the woodwork claiming some OSS had maliciously broken their code. It would quickly kill OSS. And not just that, the same principle would apply to any general publication, academic or industrial research, talks and lectures, etc. Society can't function that way.

Re: Malicious code in the purescript NPM installer

#272

Post by elliekelly »

dane-pgp wrote: post #62
elliekelly wrote: post #53

Earlier quoted context omitted.

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…

> 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.

Yup, you're definitely right. Every time it's pinged I have it download the github repo and then search for the string but your suggestion makes way more sense. If someone managed to get their ID into a popular package the repo would be downloaded & searched again and again and again. I was also playing around with it only using one repo so I hadn't really given any thought as to how it would know which repo to download if there were more than participating.

I'll dust it off, make some changes you've suggested and then put it on GitHub so @9dev (and anyone else) can take a look and tell me what else needs improvement.

Thanks!

Re: Malicious code in the purescript NPM installer

#273

Post by elliekelly »

9dev wrote: post #161
elliekelly wrote: post #53

Earlier quoted context omitted.

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…

If you're still up for this, publish the source on GitHub. That's an excellent idea and I'd like to participate :) @dane-pgp's suggestion of verifying the hack by checking the source repository is great too. Maybe it'd be easiest to just name the endpoints something like `/ping/github/ / `.

Awesome! Thanks, a ton! I haven't touched it in a while but I'll take a look at it now. I'm going to take a stab at fixing it up a bit and then I'll put it on my (currently empty!) github. I'm a bit leery of including my username in an HN comment - I once made the mistake of mentioning my twitter handle here and got some weird selfies in my DMs - so I'll put my github username in my HN profile for a day so you'll know where to look.

Re: Malicious code in the purescript NPM installer

#274

Post by dangoor »

ricardobeat wrote: post #98
SCLeo wrote: post #81

Earlier quoted context omitted.

I honestly don't understand why people use packages like this. If I need this functionality, I will simply write my own. Plus, I will never able to find this specific package. I guess PureScript uses this because its author is also the author of rate-map.

I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up. This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.

> This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.

Having had some involvement in the early days of node, I had imagined there being something like the Python stdlib. When the npm world grew, I thought "oh, that's pretty cool. It's neat how npm can handle multiple versions of the same package."

Now, I'm in absolute agreement with you. There are definitely downsides to a large standard library, but I think the upsides are worth it if that library is maintained.

Re: Malicious code in the purescript NPM installer

#275

Post by ivanfon »

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.

Agreed - I’ve found and been astonished by Github users who maintain hundreds of these little npm packages, all of which have usually under 10 lines of actual code, and sometimes even have chains of dependencies on the user’s other packages.

It seems like the only reason these packages get any significant downloads is when one of them gets depended on by a big package, causing the entire dependency chain of the user’s little packages to be downloaded.

Re: Malicious code in the purescript NPM installer

#276

Post by ivanfon »

dentemple wrote: post #254
robocat wrote: post #130

Earlier quoted context omitted.

I wish there was a way to "bless" packages when they were reviewed. I want a network of trust, such that a Google reviewed package is worth 10 points, a package fuzzed by foobar is worth 2 points, something skimmed by a dependant user is worth 1 point etc. I can then chose a compromise between a highly rated/reviewed dependencies and functionality/risk/cost-to-review. My own blessing of a package I have reviewed migh…

I would not at all trust a "Google" reviewed package, not for their penchant privacy violations and writing code to fuel them.

I assume the idea is that, even if Google violates their user’s privacy, they take care not to let others violate their user’s privacy through their dependencies.

Re: Malicious code in the purescript NPM installer

#277

Post by akamaozu »

kkapelon wrote: post #269
allover wrote: post #263

Earlier quoted context omitted.

1) As I said, it was not just JS in this situation at the time, it also applied to other major registries like PyPi. So your point does not reinforce the original attack on JS developers. Congrats to Maven for getting this right. 2) Namespaces were added later. It wasn't "a decision to make them optional". Also check out for the discussion here as to how namespaces don't solve this issue, this point is largely moot.…

4) You work for a Linux distribution. You have several global npm modules already installed that are safe and secure. You download source code of a killer app in order to package it. You check the source code itself and it is safe. However you didn't realize that there was a local node_modules directory in the git repo that contains package foo-1.2.3 with replaced code that does bad things. That package overrides you…

Sounds like your argument boils down to "check the source carefully", not "local modules are evil".

If the source was checked carefully, you'd notice a checked-in node_modules dir.

If you didn't check the source properly, you could install a module that seems like it'ss using a known package, but really is using its own malicious version of the global package.

Re: Malicious code in the purescript NPM installer

#278

Post by akamaozu »

adev_ wrote: post #264
geofft wrote: post #255

Earlier quoted context omitted.

Nobody is closing their eyes and singing "everything is fine." A large number of small packages is a good thing, and a technically strong ecosystem supports it. Having spent the last week in the internals of glibc chasing bugs in code that has no reason to be jammed into the same library that handles initial program loading, I can attest that there are good, justifiable, technical reasons to do things the NPM way, an…

> I know it's hard for you to imagine, but perhaps the JavaScript ecosystem has some good things about it. There is good in very ecosystem. But a simple keyword "node_modules" on twitter should probably convince you that the good of JS is not in its package system. To be fair, even the NodeJS author agree on that. Modularity does not mean "split your code at the atomic level".

JavaScript's package manager is a massive plus to the ecosystem.

The language would not be worth using without it.

Re: Malicious code in the purescript NPM installer

#279

Post by School-Cotton »

oefrha wrote: post #249
School-Cotton wrote: post #104

Earlier quoted context omitted.

Why do you think this? OSes like Debian don’t just pull packages from upstream automatically. Packages have actual maintainers affiliated with the OS, not the upstream community, and it’s those maintainers who build packages for the OS repos.

My software is packaged by Debian, and the update process is me notifying the Debian Developer (DD) responsible for the package of the new version => said DD pulling the new tarball from GitHub. Pretty sure no one’s gonna notice until after it’s pushed to Debian FTP if I introduce some subtle malicious code. Point is DDs don’t review version deltas for the most part, so when the upstream is compromised, they add litt…

Sure, but a very long time will pass between it being uploaded and being merged into stable, so there is a lot of time for people to discover your malicious code.

It is not like npm or crates.io where you can just upload whatever random code you like and people will start picking it up immediately.

But it’s not foolproof, sure, I agree with that.

Post reply on HN