Not actually malicious. It doesn't steal user data, drop malware, or damage a computer. Just crashes the library. Looks like another developer-developer slap fight.
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 putting tacks on the road outside of a supplier. If my truck goes there, gets a flat, and crashes into the ditch as a result, I would call that malice as well.
Deliberately crashing software that other people depend upon is malice.
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 to have code free of malice in the current javascript ecosystem ?
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?
Once again I'm reminded about that sentence someone once said. With random open-source libraries you're dealing with something someone else put out there just because they wanted to, having any kinds of expectations that someone will or won't do something is seriously short-sighted and even pretentious. Do you go around running random .exe-s you find from the internet? Why do you do so with the dependencies for your projects and expect a better end result? You may not like to hear this but it's true.
There's two solutions here, either you start reviewing the libraries you use, every release, or sign a support contract that obliges the maintainer to do something you want.
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 me pretentious until night turns back into day, and maybe I am, but the thing we're discussing is a matter of law, and it there are nuänces above and beyond what random people on the Internet would like to believe about how giving software away works.
(edited to add a pretentious diæresis)
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.
I'm also trying to tell you that your whole base premise is wrong, that even expecting some library to work or to keep working is too much (unless you apply one of the solutions I offered). Calling certain behaviors stupid absolutely has a place in a discussion about when people play with fire and then are surprised they get burnt, I think you deliberately missed my point that if you put yourself in danger you only have yourself to blame and most laws do care about that nuance. In the end the job and obligation of keeping the software you write secure is just as much on the person writing some libraries.
We can argue if x or y are effective defense in courts or not but as I said, that hasn't been tried out in the case of open-source software being broken. I also have to repeat that when you look at malicious software and changes in practice then the law applies retroactively and you have to deal with preemptive defense yourself - going back to my first point(s), you have to change the way you develop software instead of hoping what you randomly execute is good.
Hopefully you now understand what I'm trying to say to you better, English isn't my first language, sorry.
In this specific case, the code was written such that it deliberately broke installation for users. I consider that malicious. The “deliberately” is the important word here.
People make mistakes. Nobody wants this to happen, but my colleagues and I have sometimes pushed a bad deploy that broke our product, and we rushed to revert to a known good state.
That’s not malice, that’s (temporary) incompetence.
But if we deliberately broke something for our users, I would consider that malice.
Open source software is almost always distributed with a license that explicitly disavows any such warranty or liability. This is pretty widely understood...
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?
> 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.
That being said, I always get pushback when I mention this but I think SaaS projects should often be vendoring dependencies. It's safer, it's more secure, it gives you more consistent installs -- and it prevents `leftpad` scenarios. It makes source control slightly more complicated, but the other benefits (often) greatly outweigh that.
This is something that used to be more commonplace in the Javascript community, and it's something that `node_modules` makes very easy, but it's fallen out of style in modern web development.
To the best of my knowledge, this was also commonplace in the original design of Go, since it was coming out of Google, which does vendor all of its dependencies. I'm not sure which way the current Go community leans.
Sadly, this still doesn’t fix non-repudiation problems we see in ecosystems that don’t enforce things like package signing.
Which damages everything that relies on it, so... Yeah, malicious (as in `malice` and as in `let's hide it`).
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’m on my phone at the moment but if you (or anyone else) has the knowledge/interest in taking a look at what I’ve done I’d love to release it with a partner.
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.
https://mobile.twitter.com/Sc00bzT/status/730903007014076416
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!