PureScript npm installer’s infected dependencies prevented it from running successfully

Earlier this month Harry Garrood, a PureScript maintainer found that PureScript’s npm installer is infected by some malicious code. Though the issue is now addressed, developers are recommended to update the installer as soon as possible.

Which dependencies of the PureScript npm installer were infected

Garrood got suspicious when some developers started submitting an issue on the GitHub repository of PureScript’s npm installer saying that it gets stuck during installation. He found that the code was added to various dependencies of the installer, specifically the ones that were maintained by @shinnn, the original author of the PureScript npm installer. It was first inserted into the load-from-cwd-or-npm (version 3.0.2) npm package and later into the rate-map (version 1.0.3) npm package. @shinnn and the maintainers of rate-map and load-from-cwd-or-npm said that the malicious code was published by an attacker who gained access to their npm account.

The purpose of this code was to sabotage the PureScript npm installer to prevent the download from completing. This halted the installer during the “Check if a prebuilt binary is provided for your platform” step. In the first attempt of this exploit, the ‘load-from-cwd-or-npm’ package was infected so that any call to the ‘loadFromCwdOrNpm()’ method would return a ‘PassThrough’ stream instead of the expected package. In the second attempt, a more advanced version of the exploit was done by modifying the source file of ‘rate-map’ to prevent a download callback from firing.

The resolution and next steps

All the dependencies maintained by @shinnn as of v0.2.5 are now dropped. Also, all the previous versions of the PureScript installer are now marked as deprecated. If you have installed any version of PureScript npm package prior to 0.13.2, you will still be downloading packages maintained by @shinnn. It is recommended that you update the installer as soon as possible. Npm has also removed both ‘load-from-cwd-or-npm@3.0.2’ and ‘rate-map@1.0.3’ from the registry.

Garrood further suggests, “If you want to be absolutely sure you do not have malicious code on your machine, you should delete your node_modules directories and your package-lock.json files, and set a lower bound of 0.13.2 on the purescript package.”

This news triggered a discussion on Hacker News. While some think that the community etiquette is here to blame, others believe that npm packages can be easy targets of such attacks. A user commented, “This is not the first time this year we see an npm issue, and it could have been much worse than this. All package managers, in general, create risks, but how the community etiquette evolves around package managers is just as important. Something is wrong with the latter here.”

Another user added, “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.”

To know more in detail, check out Garrood’s blog post.

Read Next

Is the Npm 6.9.1 bug symptom of the organization’s cultural problems?

Surprise NPM layoffs raise questions about the company culture

npm Inc. announces npm Enterprise, the first management code registry for organizations