The Node-IPC Incident

I’ve seen the node-ipc package incident kind of blow up recently, and it’s even being covered in popular non-technical news outlets like Vice. However in almost all sources, even among developers, there is a lot of misinformation and trolls. The intense political climate doesn’t help either.

Here’s my attempt at describing the incident to a non-technical audience, as someone deeply invested in the open source and web development communities.

Setting

Node-IPC is a package released as open-source, free software, and it has been developed by a GitHub user named “RIAEvangelist” for the past 6 years. It implements something called “inter-process communication,” which is a useful building block for other software.

• RIAEvangelist has contributed the vast majority of code in this project, and he is the only user or maintainer with “push rights,” meaning that he can update the code, release new versions, and review other people’s suggestions.

• There is no one paying for RIAEvangelist’s work on this software. However, because this is free software, anyone can use the code. It is distributed according to the MIT license, which means that it is provided “as-is” without warranty, and the author allows anyone to use, copy, modify, distribute, or otherwise interact with his code at their own risk.

• Node-IPC is directly used by 355 other open-source packages on NPM (the registry of packages where it is released). It is downloaded over 1 million times per week.

• Of these 355 other packages, one of them is @vue/cli. This is part of Vue, a popular open-source web development framework. Vue is used by millions of developers, and anyone who downloads @vue/cli will also download Node-IPC as a “transitive dependency.”

It’s theoretically possible to track every transitive dependency in a package. However, developers rely on the free work of so many open-source maintainers that it’s extremely difficult to manually vet all of it (thousands of packages). Therefore, very few of the people who download node-ipc (through packages like @vue/cli) have ever heard of node-ipc directly.

Incident

At some point on or before March 9th, RIAEvangelist released a new version of the Node-IPC software. This new version includes a dependency on a package called peacenotwar by the same author, which the has been labeled as “protestware.”

Briefly, the peacenotwar package, when installed on a computer in Russia or Belarus, will create a text file on the user’s desktop that contains a simple message against the war in Ukraine.

The package does not overwrite any files and does not appear to be malicious, except for the single text file it creates. (While creating a text file is undesirable behavior, it would be extremely difficult for anyone to exploit this behavior in other ways, so this is a low-severity vulnerability according to Snyk.)

However, there is a separate part to this incident. At around the same time as the peacenotwar package was published, there are claims (unverified) that RIAEvangelist added obfuscated code in node-ipc that indiscriminately deletes files on the user’s computer when it is installed, if it detects that the user is from Belarus or Russia.

It is difficult to verify these claims because the affected versions of node-ipc have since been removed from NPM and their source code wiped from the public record.

That said, if true, this is an extremely dangerous piece of malware. Anyone whose computer’s location is set to Belarus or Russia, who then creates a new project with @vue/cli, or explicitly updates the dependencies of an old project using @vue/cli, will have files on their computer silently deleted with no trace or backups.

The node-ipc issue is considered a critical-level vulnerability by Snyk — which is the highest severity level (9.8/10), and it has been assigned an identifier CVE-2022-23812 in the US national vulnerability database.

Response

There is a long history of unsustainable practices in the open-source ecosystem. For example, maintainers are unable to be paid adequately for their work, even if it impacts millions of users. In the past, when one individual did so much as display unobtrusive messages asking for donations in the terminal of people who used their free software, there was intense backlash despite the author not harboring any ill-intent. This was feross/funding — also see “Open Source is Not About You” for writing about similar issues in the Clojure community.

There is also a history of mission-critical software around the world relying on the largely unfunded and unknown volunteer work of open-source maintainers, who just do this as a hobby. Extremely severe vulnerabilities like those in OpenSSL (search for SSLv3 POODLE or Heartbleed) and Log4j (search for Log4Shell), which created widespread panic, were resolved by pretty-much unpaid volunteers taking time out of their weekend to stop the entire digital world from burning. See XKCD 2347 for a depiction of this.

Finally, there is a history of these so-called “supply-chain vulnerabilities” where the vast majority of software today depends on small libraries that random individuals around the world have push access to. This creates a large surface area for large projects, which depend on small projects, to be broken. The most famous example of this was the “left-pad” incident.

Given this context, it’s important to note that RIAEvangelist has no responsibility to fix bugs in his node-ipc package because it is provided “as-is.” He is contributing code to the world for free and allowing anyone to use it, and no one is paying him for his volunteer work.

However, what distinguishes this problem from the past is that RIAEvangelist actively added code with malicious intent that harmed unknowing users in Russia and Belarus. This is malware, and it’s hard to find any ethical justification for his actions. While it’s clear this stunt indicates that his work was under-appreciated, given how many millions of people use the code, it’s also extremely harmful and sets a dangerous precedent for supply-chain attacks.

These attacks are not unique to NPM. For a personal example, consider Crepe, an open-source library I develop and maintain in the Rust ecosystem. Crepe is used by companies including Teleport, whose open-source software is hosted open-premises of their customers like Nasdaq, IBM, and Samsung. If a technical attacker were to compromise my email and gain publishing rights to Crepe, they could publish new versions of Crepe with embedded malware at compile-time. The next time Teleport updated their dependencies (similar to this attack), this arbitrary code could run on all servers compiling and running Teleport, allowing them to hack both developer machines and production infrastructure (e.g., deleting all of the files on Nasdaq’s computer).

This is not good, and I just want to emphasize that Crepe is not unique. I ran an analysis on dependencies of Crepe, and there are over 45 people who have “push access” to publish updates to packages that Crepe relies on, and over 14 teams of people (of which we can’t get the member list without permission). All of these are single points-of-failure that can compromise any users of Crepe through transitive dependencies.

Now, Crepe is a relatively small library with only 78 dependencies, since I intentionally kept it minimal. Typical software projects using NPM will have thousands of dependencies (e.g., the code powering my website setwithfriends.com). It’s conceivable that your average web application has on the order of 10,000 people around the world who have push access to the supply chain. Any of these people can push code that wipes your disk, the next time you update dependencies.

Anyway, the issue being raised here is that people play too fast and loose with security, trading it off for productivity. What’s beautiful about modern software is that you can release new code to millions of users around the world in minutes; however, the current state of the software supply-chain means that you can also release malware to millions of people in minutes.

Releasing malware is incredibly dangerous; you can ruin people’s lives and/or go to jail yourself. These kinds of incidents raise public awareness about the tenuous trust relationships in software that the entire world depends on, whether they’re conscious of it or not.

Primary sources

I strongly do not recommend trusting anything you read from popular news sources about this incident. Most writers seem to be misguided and very confused, since the problem is recent and requires some technical background to understand. Here are the original sources.

• Node-IPC on NPM
• Node-IPC on GitHub
• Peacenotwar on GitHub

If you have additional information or find anything in this post factually incorrect, please send me a message @ekzhang1.