The developer of a popular JavaScript component hosted on the npm repository decided to protest Russia’s invasion of Ukraine by adding code to his own component that would add or delete files on people’s computers in a way they didn’t expect. The component, called node-ipc, is a dependency for a variety of other projects, which had to issue emergency updates to stop the undesired behavior they unwittingly inherited.
It’s the second time something like this has happened this year in the Nodejs community, and some people have started referring to such acts of self-sabotage by developers as protestware. Experts believe that while developers certainly have the right to modify their own software, such acts risk damaging trust in the open-source ecosystem, which has faced increased supply-chain security challenges in recent years.
What happened with node-ipc?
Node-ipc is a nodejs module for local and remote inter process communication with over 4 million monthly downloads on the npm repository. It is a dependency for over 350 other npm components, including popular ones like the command line interface (CLI) for the Vue.js JavaScript framework or Unity Hub, a project related to the Unity game engine.
Over the past week the developer of node-ipc, who uses the name RIAEvangelist on GitHub, released several updates to the still supported versions of node-ipc to add malicious code to the component. This was first spotted by another developer named Tyler Resch, known as MidSpike on GitHub, who opened a report on the node-ipc bug tracker on March 9. Some of his comments in the discussion thread were later deleted by RIAEvangelist so Resch documented them in a separate repository.
According to an analysis by researchers from developer security firm Snyk, it all started on March 8 when RIAEvangelist, who is the maintainer of over 40 components on npm, published a component called peacenotwar on the registry. This component writes a file called WITH-LOVE-FROM-AMERICA.txt on the user’s desktop with messages protesting the war in Ukraine in several languages. That same day, the developer also released a new major version of node-ipc called 11.0.0 that added peacenotwar as a dependency.
Things escalated on March 15, when RIAEvangelist decided to also release node-ipc 9.2.2, an update to the 9.x branch of the module, adding peacenotwar as a dependency to this branch as well. The 9.x branch is considered the stable version of the module and is the most widely used, drawing massive attention to the issue as users of multiple projects that use node-ipc started finding the new file on their systems.
Signs of software supply chain malware
However, it turns out this was not RIAEvangelist’s first attempt at sabotage through node-ipc. After spotting peacenotwar, Tyler Resch looked back through code commits and found a suspicious one on March 7 that added a file called ssl-geospec.js. This file had code obfuscated in base64 that, when executed, reached out to a remote geolocation service to test if the system’s IP address was based in Russia or Belarus. If the result was true, the code proceeded to overwrite all files on the system volume with a heart character. In essence, this was destructive behavior intended to sabotage the systems of Russian and Belarusian users.
According to Snyk’s analysis, this malicious code was added to node-ipc version 10.1.1 on March 7 with no mention of it in the changelog or readme. Around 10 hours later, another version called 10.1.2 was released with virtually no code changes. According to the researchers, this second release might have been an attempt to trigger automated dependency upgrades. After another 5 hours, on March 8, RIAEvangelist released version 10.1.3, which removed the malicious code.
Mitigation and supply chain trust
At this time, versions 9.2.2, 10.1.1 and 10.1.2 have been removed from the npm registry. Version 11.1.0 remains but the module’s description page now has a note that v11 contains the peacenotwar dependency.
On the node-ipc bug tracker the maintainer argued that: “It is documented what it does and only writes a file if it does not exist. You are free to lock your dependency to a version that does not include this until something happens with the war, like it turns into WWIII and more of us wish that we had done something about it, or ends and this gets removed.”
Locking or pinning the dependency to a safe version on node-ipc is what the Vue.js maintainers did and is good practice. Snyk also recommends using the “overrides” feature of the npm package manager to exclude any impacted versions. However, this feature is only supported in npm version 8 and above. The Yarn package manager also supports selective version resolutions.
GitHub, which operates the npm registry, has published security advisories for both the file overwriting and peacenotwar issues. The incident raises a lot of questions: Can this maintainer be trusted in the future? Should his privileges to publish projects on npm or other repositories be revoked? What if more developers resort to sabotage acts like these? In January, two other popular modules called colors and faker were intentionally sabotaged by their maintainer. Is protestware going to become a common problem?
“Even if the deliberate and dangerous act of maintainer RIAEvangelist will be perceived by some as a legitimate act of protest, how does that reflect on the maintainer’s future reputation and stake in the developer community?,” Liran Tal, Snyk’s director of developer advocacy, said. “Would this maintainer ever be trusted again to not follow up on future acts in such or even more aggressive actions for any projects they participate in?”
“When it comes to this particular issue of trust, I believe the best way for it to be handled is with proper software supply chain hygiene,” Brian Fox, CTO of supply chain security firm Sonatype, tells CSO. “When you’re choosing what open-source projects to use, you need to look at the maintainers.”
Fox recommends exclusively choosing code from projects backed by foundations such as the Apache Foundation, which don’t have projects with just one developer or maintainer. With foundations there is some oversight, group reviews and governance that’s more likely to catch this type of abuse before it’s released to the world.
“This isn’t just about the code being contributed,” Fox says. “It applies to dependencies as well. Foundations use the same diligence with dependencies, again, making this much less likely to be a concern and why maintainer hygiene is so important to consider when picking a project.”
According to Fox, Sonatype supports the rights of developers to do what they choose with the code they own, but as the stewards of a repository themselves — Java’s Maven Central — the company made it very clear that it will remove anything that’s truly malicious. “We support the right of the developer in this instance, but repositories should not host code that is truly malicious in nature — and we may not feel comfortable hosting his code in the future.”
Copyright © 2022 IDG Communications, Inc.
