The maintainer of a widely used open source module for Windows, Linux, and Mac environments recently sabotaged its functionality to protest the war in Ukraine and in the process focused attention once again on the potentially serious security issues tied to code dependencies in software.
Brandon Nozaki Miller, author of node-ipc, a JavaScript module for interprocess communication that millions of developers use when building software, recently inserted code into the software for deleting all files on developer systems geolocated in Russia and Belarus.
He later quickly removed module versions containing the wiper code from the npm JavaScript registry on which it was available, but then published another module called “peacenotwar” and made it a dependency of node-ipc. So, developers that downloaded node-ipc ended up having a file with Ukraine war-related messaging placed in their desktop directory. The node-ipc module averages more than one million downloads a week, across all versions.
Application security vendor Snyk, which investigated the incident this week, described it as an example of an act that undermines the global open source community. “This security incident involves destructive acts of corrupting files on disk by one maintainer and their attempts to hide and restate that deliberate sabotage in different forms,” Snyk’s director of developer advocacy Liran Tal said in a blog. “While this is an attack with protest-driven motivations, it highlights a larger issue facing the software supply chain: the transitive dependencies in your code can have a huge impact on your security.”
The node-ipc incident is the second one in recent months to highlight the serious risks that enterprises run from using open source and third-party components to build software.
In January, Marak Squires, the maintainer of two very widely used open source libraries — colors.js and faker.js — intentionally introduced code into the modules that caused applications relying on them to print the word “liberty” multiple times followed by gibberish. Sonatype, which maintains the Maven Central Java package repository and investigated the Squires incident, described ‘colors’ as having more than 3.3 billion downloads and as being used in over 19,000 projects and ‘faker’ as having more than 272 million downloads and about 2,500 dependent projects. So, thousands of applications were impacted by Squires’ action, which Sonatype surmised might have been a form of protest by Squires over what he considered as big companies and commercial projects benefiting for free from his work.
Dangerous Meddling
Snyk’s analysis of the latest node-ipc incident showed that Miller, who uses the handle RIAEvangelist, published two node-ipc versions containing the destructive code (10.1.1 and 10.1.2) just hours apart on March 7, 2021. The corrupted modules were available for download on the npm JavaScript registry for less than 24 hours before they were removed. Even so, the high number of downloads associated with node-ipc make it certain that at least some developers that use the module in their code were impacted, Tal said in comments to Dark Reading.
“The destructive versions 10.1.1 and 10.1.2 were removed from the registry of npmjs before we [were] able to collect any download stats for them,” he says. However, the 10.x version branch of node-ipc has about 3,000 downloads a week, so it is safe to assume that nearly the same amount of downloads contained the wiper code.
Miller published the peacenotwar package on NPM a day later, on March 8. He described the module as both as a protest against Russian aggression in Ukraine, and as a “non-destructive” example of why developers need to exercise more control over node modules. “[This] should serve as a safe example of why teams should use explicit dependency versions,” Miller said in a GitHub thread. “It is always our choice to upgrade or not.”
Tal says that the peacenotwar module at first received barely tens and hundreds of downloads, but, once it was added as a dependency of the mainstream node-ipc branch, it received more than 40,000 downloads. “Keep in mind though, this module is the lesser destructive ‘protestware’, although still quite alarming for end users.”
In a statement, Sonatype CTO Brian Fox said the recent incidents show why developers should vet the maintainers when choosing open source modules for use. He recommended that developers should almost exclusively choose code from projects backed by foundations rather than individuals. Choosing a project with just one maintainer means putting trust in one single developer, Fox said. Open source projects that are backed by a foundation tend to have controls that make it very hard for a single developer to completely alter code on their own, he noted.
“It’s impossible not to look at what happened with peacenotwar and node-ipc and immediately relate it to what happened with ‘colors’ and ‘faker’ which was another act of protest,” he says. “You can debate the validity of this protest, but this type of behavior absolutely contributes to trust issues apparent within open source.”
Tal says that prior research has shown that nested dependencies compound significantly with every module that is added to software that is being built. He points to one study in 2019 that showed developers installing an average npm package implicitly trust 80 other packages due to transitive dependencies. “Some highly popular packages reach more than 100,000 other packages, making them a prime target for attacks,” he says.
Supply chain security concerns have increased and should be top of mind for any developer, startup, or enterprise, Tal says. Security concerns range from maintainer reputation to licensing, security vulnerabilities, and maintainability of the project. “Developers should carefully review the open source component’s overall health score which spans all of the aforementioned characteristics, and more.”
