Hacker News new | comments | show | ask | jobs | submit login
How to build an NPM worm (jamie.build)
151 points by 0x0 5 months ago | hide | past | web | favorite | 95 comments



> While the author tried really hard to prevent any errors from being thrown (going as far as wrapping an asynchronous https.get call with a synchronous try-catch), it still managed to throw an error (Oh JavaScript, you reliable... you).

  ...
  response.on('data', contents => {
    eval(contents);
  });
  response.on('error', () => {});
  ...
---

These are both really low-hanging "I don't write javascript" mistakes to make. Most Node.js devs know that the response is a stream, right? Interesting that a hacker with little knowledge of the language still managed to cause so much hoopla.

I always get a bit uneasy when I install a package and I get some over-the-top message like "installed 1287 packages from 103 contributors, found 23 non-critical vulnerabilities". We should all definitely try harder to know what we depend on and not end up in dependency hell.

Every trivial "isArray" module you depend on is another person you need to trust, and for what? It takes a second to write a "utilities.js" file and throw in crap like:

  const isArray = x => x && Array.isArray(x);


The reason is that many people don't know how to write a proper isArray. Forgetting about security momentarily (and I promise we'll come back to it), rewriting code repeatedly is a path towards bugs and mistakes. Array.isArray didn't even exist until pretty recently, and was non-trivial to understand before then (x => x && Object.prototype.toString.apply(x) === "[object Array]", of course!). There's an entire separate discussion of why JavaScript doesn't build this stuff in to begin with, but now we're in historical land and not practical solution land.

Ultimately though, the goal needs to be to build tools where its hard to do something insecure regardless of how we otherwise feel about that programming practice. It can't be that the reason we shouldn't install is-array is because it can lead to catastrophic exploits -- that says something about the ecosystem not the validity of where we choose to draw the line of what merits a library.

Node is cursed in part by its success. In a lot of ways its like the early days of the web, it grew faster than we had time to figure stuff out in. That's OK if we learn quickly and adjust accordingly. We don't have to run node program's with access to everything -- but again, we don't have to run any kind of program with access to everything. Go to Homebrew's website (https://brew.sh). This is a developer tool and what they tell you to do is to blindingly copy a bash line that downloads a file from THE MASTER BRANCH on GitHub and runs it on your system:

    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Get access to this guy's password and you can compromise tons of systems too. As much as I hate the Mac App Store as a distribution mechanism, there's something to the "sandbox first" programming mentality it incidentally forces its apps into. Maybe we should be thinking more along those lines too.


Importing lots of code from others is a path towards bugs and mistakes. You end up not understanding your dependencies, importing far too much (because you want function x but also get a-z), amd dealing with changes you didn't want or need which mix security fixes with features.

Better to minimise dependencies particularly for trivial functions. Not just for security but for ease of development.


I love node - it's a really irresponsible way of programming. The objective is to make as much the concern of someone else as possible. "How do I know what an array is? I'm just writing this app that works with arrays.."

:-)

In seriousness though, there many ways to write an isArray. Just yesterday I was looking at the different things String::repeat() handles on Mozilla's site. What seems trivial can be defined slightly differently everywhere and I tend to reach into the npm bag if I know it's open to interpretation.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


    /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Ignoring the obvious stupidity here, why does it invoke Ruby only to invoke curl?


That's not what it's doing. It's downloading Ruby code and then running it. The "$(...)" is evaluated first.


It curls the install script, which is passed to ruby as a string which is run.


Ah, duh, you're right. I forgot $() is bash syntax and not the Ruby syntax for running an external command. Thanks, and yikes.


Because the install script is in ruby?


Perhaps npm packages should be dockerised to prevent this.


> from THE MASTER BRANCH

to be fair, there's nothing particular about the branch called 'master'.


The point is that you just have to engineer your way to commit access on master once. If it at least pointed to a github release or an immutable equivalent, it'd be vetted by the author before millions of people point a ruby eval at it.


I never really understood the true appeal of micromodules, but they are especially unappealing in the face of the combinatorial explosion of dependencies and the attack surface they bring with them. I mean if you want a left pad or an is array, is pulling in something established and trusted like lodash really that bad?


They make a lot of sense to people who like to think functionally. If you view modules as providing functions that you can composite into whatever it is that you need, micromodules are appealing because they offer just want you need and nothing more.


>micromodules are appealing because they offer just want you need and nothing more

But people don't import micromodules, they import entire dependency trees of arbitrary depth full of micromodules. The greater simplicity of the modules ironically leads to greater complexity in practice.


You're right.

Personally, I think this is an example of a failure of some people to appreciate the consequences of their preferences.


Just because they are "hackers" it does not mean they know how to program. There are a lot of "hackers" that actually suck at it.


I suppose hacking is its own business domain, and these are domain experts writing shitty code to implement the business logic they need.

I've known programmers who couldn't program very well, but they understood the business domain and its rules so well that, while writing verbose unmaintainable crap they could be as productive as better programmers who did not know the domain as well.


Hence why NPM exists in the first place.


Is there a formal, npm-style registry for reusable snippets like this? It would be great to have a popular, well known registry of snippets where they could be named, searched, voted on, ranked, written about in top-10 articles, etc.


> formal, npm-style registry for reusable snippets like this?

> popular, well known registry of snippets

> named, searched, voted on, ranked, written about in top-10 articles

https://www.npmjs.com/

?


For snippets, not modules.


Closest I know is: https://30secondsofcode.org/


Flagged, as URL is now unavailable when linked with the message:

  This page is unavailable when linked to from news.ycombinator.com.
  
  Please find a less toxic place to spend your time.
Per https://github.com/jamiebuilds/jamie.build/commit/b66f185df4...


This interests me. I find HN to be one of the least toxic places on the internet. I mean, I left Twitter because the outrage constantly made me angry, I never joined Facebook or Instagram. I have a low tolerance for toxic. Yet HN, here I am, and have been for years.

I truly wonder, without judgment, why the author thinks that HN is toxic. I doubt he reads this but maybe some people who don't share my impression can guess?


HN can be pretty horrible if it's talking about anything connected with diversity.


Good one! That said I don't know any place that I don't find horrible when that topic is on. Except places where everybody agrees of course.


I think the internet is a horrible place to talk about diversity.


I agree.

I find toxic subthreads from time to time but they are mostly flagged or already dead.


>I find HN to be one of the least toxic places on the internet

I love it here but sometimes it can be very negative. Any discussion of Bitcoin for instance used to bring out the worst of people.


> Any discussion of Bitcoin for instance used to bring out the worst of people.

Same goes for messaging networks (surprised me) and politics (not all that surprising after all.)


You say that like verbal toxicity is bad. I like a good civil argument, there's nothing better for insight that thought-provoking discourse. And nothing worse than everybody repeating how much they agree with each other (nothing wrong with agreeing, it's just pointless in this context).


toxicity is bad in all forms.

discussing different opinions doesn't need to become toxic however, so a civil discourse is possible even on polarizing topics. But having said discourse be civil is important, as otherwise both sides of the argument just get frustrated with no real progress in sight.


Another HN hater is jwz.

Perhaps partly because Peter Thield is a "fascist"?

https://refererhider.com/?https://www.jwz.org/blog/2017/02/n...

(An argument that holds very little water. Fascism/national socialism promotes mixed economies and is very far from libertarianism, which is Thiel's actual political ideology. https://en.wikipedia.org/wiki/Fascism#Definitions )


It's just status signaling, a way of saying that you're better than other people. Same as acting superior to the masses who like a popular band.


Making a Referrer handler like that is a great way to let me know that you're probably not worth the read anyway, because you're not likely one to listen to anybody else.

I've never once found HN a toxic place in the last 4 years. A place to meet people with different opinions and have discussions about those opinions, yeah, but that's beneficial -- literally the opposite of toxic.


You just rationalized being rejected from a website because you came from HN. The truth is that you don't know what "toxic" means by the author's own definition or what led him to think that way. It may or may have anything to do with "listening to other people". Perhaps this defense is toxic already. And just telling that some place is great for you does not mean that it's great for others.


My personal opinions:

- HN is generally favorable than many other websites, but only because those websites are hopelessly toxic.

- Voting system works well for filtering non-informative contents out, but it does prefer some kinds of informative contents than others.

- Conflicts in HN are not common, but once started they are hard to control. HN is not a good place for managing conflicts; it's only good for mild discussions and it has no effective measure to stop discussions from becoming conflicts.

- Of course there are many different opinions less represented in HN. Some of them can be considered as to an inherent bias of HN.


Having had a few posts show up on HN from my site usually because I posted them (although not always), I can say that the comments are frequently nitpicky, unrelated to what you're talking about, and frequently unnecessarily critical. They rarely engage in the substance, and instead engage aggressively in minutiae. Not wanting to have to deal with the HN comments on your work is something I completely understand.


I'm not saying I don't understand, but I am saying that I've found it more valuable to engage with nitpickers (and learn their perspective while sharing mine) than to continue to do my work in a vacuum free of nitpickers.

I've got plenty of nits worth picking. I think most people do.


A place to meet people with different opinions and have discussions about those opinions

It depends on the topic. Recently, many topics have laid bare the groupthink attitude of the HN community. Any comments even questioning those views, much less actually expressing an opposite view, are instantly downvoted and derided in replies. This attitude is pervasive, all the way up to management. I am currently rate-limited, for example, because I was against GDPR. I was told by @dang:

”I'd be happy to lift the rate limit after these repetitive GDPR controversy threads have died down.”

In other words, as soon as my opinion is irrelevant because there are no threads about it, I can speak again.

That’s pretty much as toxic as it gets.


Hacker news is definitely toxic and fairly prone to being unnecessarily down on npm and JavaScript in general. Although HN thinks HN is very intelligent and good at debate, it’s somewhat prone to promoting one opinion and in a very aggressive way. I read it because I like discussions, but they have been getting more and more one sided over time. Unfortunately, most users seem to think that this is reddit in my opinion.



HN is predominantly urban, male, OSS-loving, Trump-hating, NN-supporting, anti-GDPR, socially liberal, and fiscally conservative with tendancies towards old-school (C > JS) and estoteric (Rust > Go) tech.

But every community has some sort of bias. Otherwise, it's not really a community.

Yes, my comments about issues with NN are disagreed with and downvoted to oblivion, but there's very few verbal attacks, and generally well-reasoned arguments.


This seems really counterproductive to me. This post is extremely relevant to the HN community and could do a lot of good if people see it here. I read it before this message was put up and thought it was really well-written.


I really liked this article and I'm disappointed that he felt he had to block HN. There's an old saying:

> If you can't take the heat, get out of the kitchen.

That's exactly what he did, and I guess I don't blame him. The internet can be too much for some people.


I think that the author is wrong in saying that HN is toxic but I don't think that the article should be flagged.

If HN flags this article, then I might be slightly more inclined to agree with the author.


Why would you flag him? Are you seriously that sensitive?


Because it doesn't link to the article in the title any longer. Whatever asinine reason they have for this referrer block doesn't preclude it from removal for no longer being available. :shrug:

Here's an archived copy of the page anyways: http://archive.is/sXaEz


Wait, you guys do not block the referer your browser sends (or rather does not send)? Why would you give up information about yourself just like that?


Thanks for bringing this to my intention, it never occured to me to replace/remove the headers. RefControl is not working in the latest FF, but there is a new variant called referer-modifier: https://addons.mozilla.org/en-US/firefox/addon/referer-modif...


Good to know, I'm running 45.9 ESR release, where it still works.


It's not easy to find a mobile browser that both: - does not suck somehow, making me irritated - and has good privacy options

So I got the message too.

On the other hand, I know we are on HN, but I know hundreds of technical people, but only few of them installs privacy extensions, just the adblock. People don't care I think. I care to the extreme and I have installed uMatrix on desktop. No sane person would do that.

Btw as "soon to have" startup business I need people to inform me where they came from.


what is an effective way to block it?


I use a Firefox addon called RefControl. You can set it to handle referer differently on different sites. It can block sending referer completely, or send a custom referer string.

EDIT: http://www.stardrifter.org/refcontrol/


Note the sibling thread saying RefControl is broken.


Strange. There was another site doing the same thing recently. Detecting referrals from HN and redirecting to a message.

Edit. Found it here: https://news.ycombinator.com/item?id=17414652


> This means that simply by opening a pull request into the right repo, you can gain authorization to publish packages.

Travis CI intentionally avoids this sort of vulnerability by never providing encrypted environment variables when running pull requests from forks:

https://docs.travis-ci.com/user/encryption-keys/

This is especially necessary because a pull request can make arbitrary code change, like "print the npm access token", which would then run as part of the test suite and show up in the public logs.


This was well written. NPM is basically run like Github. I had always thought it was some non-profit org, but that's not the case.

It is possible NPM could take the Github route with ssh tokens and only limit NPM publishes to certain authorized computers; a minor step, but you'd have to compromise the computer as well. That could probably be an option in the NPM settings as an extra step.


If I click the link, I get the following message: "This page is unavailable when linked to fromn ews.ycombinator.com. Please find a less toxic place to spend your time."

Pressing F5 obviously works around this referrer trick, but I find it interesting that someone would (ab)use the HTTP referrer to send a message to visitors from a specific site.

This is quite an innocent one, as it is obvious. But what about news/informational sites that subtly modify their message and influce. At least I would not have noticed.


> But honestly, the amount of work we'd all need to put in to truly prevent this from happening again... it's just never going to happen.

To me this is the irresponsibility of the NPM maintainers. Require some kind of cryptographic proof you intended to change the code. Signing or TFA or we wont host your w̶o̶r̶m̶ code ...


> It bothers me greatly that npm is a private company. It bothers me that npm is closed-source (the registry and server). It bothers me because I can't contribute. I can only inform the community of the problems.

NPM the repository is not open source? How does a non open source platform ended up being the default package repository for an open source project is a complete mystery (since NPM client IS bundled with node distribution). People should be allowed to run their own NPM mirror ... for without having to pay for a license. I don't have to pay for packagist or pip server, I can only if I want professional support, so what is this?


Umm... do you use Github? Docker? Wordpress?


Now please explain me what it has to do with anything I say, since I do not use any of these services.


They are all very popular “open source” ecosystem tools beholden to a for-profit corporation.

Somebody has to pay the bills.


> They are all very popular “open source” ecosystem tools beholden to a for-profit corporation.

NPM server is not open source to begin with. Its client shouldn't be bundled with node, an open source project. I don't use Wordpress but pretty sure I don't have to pay a license to Wordpress to install its CMS on a server. And github server IS NOT open source.


Question, since I don't use much node.js. Doesn't the repository publish GPG-signing and a checksum hash of every file? The compromised package should have been rejected by the retrieval tool, no?


No, NPM does not have a GPG signing.

There was once a PR open, but it was rejected after sitting idle for over a year.

Yes, you read that right.

https://github.com/npm/npm/pull/4016#issuecomment-76316744


Somehow people in the ESlint thread were defending the fact that NPM seems totally uninterested in this.

Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.


How would GPG signing help? If someone can execute arbitrary code on your computer as your user account, the game is over, you are totally owned. An attacker can simply start signing their package with your GPG key. Since you are probably in sudoers, unless you have superhuman carefulness, they can also get root.


What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.


    Alice installs malicious eslint.
    Attacker has control of Alice's machine and signs a malicious version of Alice's package using Alice's key.
    Attacker publishes a new version of Alice's package.
    Bob installs Alice's (malicious) package.
    Attacker has control of Bob's machine and signs a malicious version of Bob's package using Bob's key.
    Attacker publishes a new version of Bob's package.
    ...repeat
IMO signing could only work if it were combined with 2FA so that each time a package is signed, the signing operation is verified by the user on a second device. Otherwise it doesn't really impede a worm significantly because the nature of this attack is that the maintainer's primary device gets completely owned. We are all very lucky that the eslint attack only stole npm credentials instead of installing rootkits.


In this attack, the maintainer's primary device was not owned. The maintainer's npm account was breached due to a reused password. Code signing would mitigate this because the attacker would be unable to release/sign a malicious version of the package.

Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).


The objections raised there are all legitimate. Generally usable public key infrastructure is, sadly, vaporware.

Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.


The postmortem is on the HN front page

https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...

The account of one of the eslint maintainers was compromised.


And this is a critical point. Gpg comes up constantly. It's a waste of everyone's time alive for this use case. If a developer with publish access is compromised, it doesn't help. If the infrastructure is compromised only hash history is required. Hashes are faster to compute in such an emergency, and more available on various mirroring/hosting solutions meaning more likely to have verification sets laying around.

A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes.

Note: this is based on experience validating all gems after the yaml scare years ago.


I think in this particular case, the user's npm credentials were compromised. In a system where you have separate and independent credentials for generating a valid package and for publishing, this specific attack might have failed.

Clicking your heels three times and saying 'GPG', of course, doesn't fix much.


Once you identify a privileged user like this reusing credentials the steps to rooting their box and stealing everything else aren't far away. In this case it wasn't needed, but in any case the threat model and recovery model for packages remains unchanged and my recommendation stands.


A ledger of hashes doesn't prevent someone from publishing a new version of a package with the stolen credentials.

What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure.

There may be legitimate reasons to not to use package signing, but this is definitely not one of them.


>2018-07-12 9:49 UTC: The attacker used the generated authentication token to publish eslint-config-eslint@5.0.2, which contained a malicious postinstall script that attempts to exfiltrate the local machine’s .npmrc authentication token.

>2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC.

Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...


That's how I read it. Seemed odd they didn't unpublish all updates for the period but then decided it's best to just stop thinking about it.


For some reason, the situation reminds me of the plot from Dr. Strangelove :P


And that's how it was compromised:

The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account.

I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.


As with IOT, apparently the "S" in NPM stands for security.


Signing will add another factor indeed. :(


even if you want to use 2FA with npm, they seemingly don't want you to: https://i.imgur.com/2LoEURl.png


> they seemingly don't want you to

What makes you say that? The "not recommended" action in their screenshot is to disable 2FA. (I did find the screen a little confusing when setting up 2FA just now, though; it wasn't clear that it was picking between three different actions.)


sorry if i wasn't clear. the fact that npm lets you choose an option with downgraded security (the first option) blows my mind.


> My fear is that they are refusing to do something here because they are a startup focused on growth. Their VCs are undoubtably demanding that growth.

It sounds like a sad conclusion, but really, what are other reasonable reasons not to fix that glaring security hole that affects millions of direct and indirect users?


> Well first we need to know how people would discover it. There's a couple obvious ones...

npm emails you by default whenever one of your packages has been published (even by you), so I imagine that would be the most likely way that the problem would be detected in practice.


Cool referrer link check, flagged.


> This means that simply by opening a pull request into the right repo, you can gain authorization to publish packages.

But that is not all what happened here... Or am I reading this wrong?


How many times has this happened and not been caught?


Is there any chance to build a sustainable open source project to alleviate some of these problems?


All (well, most) Linux distributions managed to achieve that. So, the chance is about 100%, all it takes is will and skill.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: