Developer sabotages own npm module and raises questions about the security of the open source supply chain
It’s the second time something like this has happened in the Nodejs community this year, and some people have started labeling such acts of developer self-sabotage as protestware. Experts believe that while developers have the right to modify their own software, such acts risk damaging trust in the open-source ecosystem, which has faced increasing supply chain security challenges in recent years was faced.
What happened to node-ipc?
Last week, the developer of node-ipc, who goes by 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 and opening a report on the node-ipc bug tracker on March 9th. Some of his comments in the discussion thread were later deleted by RIAEvangelist, so Resch documented them there a separate depot.
Accordingly an analysis by researchers at developer security firm Snyk, it all started on March 8th when RIAEvangelist, the maintainer of over 40 components on npm, released a component called peacenotwar to the registry. This component writes a file called WITH-LOVE-FROM-AMERICA.txt to the user’s desktop with messages in several languages protesting the war in Ukraine. On the same day, the developer also released a new major version of node-ipc called 11.0.0 which added peacenotwar as a dependency.
Things escalated on March 15 when RIAEvangelist decided to also release node-ipc 9.2.2, an update for the 9.x branch of the module, and also added peacenotwar as a dependency on that branch. The 9.x branch is considered the stable version of the module and is the most widespread, which draws massive attention to the issue as users of several projects using node-ipc started finding the new file on their systems.
Signs of malware for the software supply chain
It turns out, however, that this wasn’t RIAEvangelist’s first attempt at sabotage via node-ipc. After Tyler Resch discovered Peacenotwar, he looked again at the code commits and on March 7 found a suspect adding a file called ssl-geospec.js. This file had code obfuscated in base64 which, when executed, contacted a remote geolocation service to test whether the system’s IP address was located in Russia or Belarus. If the result was true, the code would overwrite all files on the system volume with a heart character. Essentially, this was destructive behavior aimed at sabotaging 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 7th without any mention in the changelog or in the readme file. About 10 hours later, another version called 10.1.2 was released with virtually no code changes. According to the researchers, this second version may have been an attempt to trigger automatic dependency upgrades. After another 5 hours, on March 8, RIAEvangelist released version 10.1.3, which removed the malicious code.
Mitigation and trust in the supply chain
At this point, 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 includes the peacenotwar dependency.
On the Node-IPC bug tracker, the maintainer argued that: “It’s documented what it does and only writes a file if it doesn’t war like it’s turning into WWIII and more of us wish, that we have done something about it, or ends and this is removed.
locking or pinning Dependence on a secure version on node-ipc is what the Vue.js maintainers did and is good practice. Snyk also recommends using the npm package manager’s “overrides” feature to exclude affected versions. However, this feature is only supported in npm version 8 and later. The Yarn package manager also supports selective version resolutions.
GitHub, which runs the npm registry, has published safety notices for both file overwriting and peacenotwar issues. The incident raises many questions: Can this maintainer be trusted in the future? Should his privileges to publish projects to npm or other repositories be revoked? What if more developers resort to such acts of sabotage? In January, two more popular modules called Colors and Counterfeiters were deliberately sabotaged by their supervisor. Will protestware become a common problem?
“Although maintainer RIAEvangelist’s intentional and dangerous action may be perceived by some as a legitimate act of protest, how does this affect the maintainer’s future reputation and stake in the developer community?” Liran Tal, Snyk’s Director of Developer Advocacy, said. “Would this supervisor ever again be trusted not to follow up on future acts in such or more aggressive actions for projects in which he participates?”
“When it comes to this particular trust issue, I believe the best way to deal with it is with proper software supply chain hygiene,” Brian Fox, CTO of supply chain security firm Sonatype, told CSO. “When deciding which open source projects to use, you need to look at the maintainers.”
Fox recommends only selecting code from projects supported by foundations, such as the Apache Foundation, that do not have single-developer or single-maintainer projects. With foundations, there is some oversight, group audits and governance that are more likely to uncover these types of abuses before they are released to the world.
“This isn’t just about the contributed code,” says Fox. “This also applies to dependencies. Foundations take the same care with dependencies, which in turn makes this less likely to be an issue and why caregiver hygiene is so important when choosing a project.”
According to Fox, Sonatype supports the rights of developers to do what they want with the code they own, but as the maintainer of a repository itself – Java’s Maven Central – the company has made it very clear that it will remove anything is really malicious. “We support the developer’s right in this case, but repositories should not host code that is truly malicious in nature – and we may not feel comfortable hosting its code in the future.”
Copyright © 2022 IDG Communications, Inc.