March 28, 2022 • RBS

Categories: Security News

The Open Source Software (OSS) community has been split in two after an OSS author repurposed his own library to protest the Ukrainian-Russian war. On March 7, RIAEvangelist released several versions of his ‘node-ipc’ software package, with some versions reportedly overwriting code on machines presumably located in Russia and Belarus. His actions have sparked a massive controversy and has given birth to a new surge of “protestware”, where other similar-minded developers may target Russian-based machines. Regardless of where you stand, there is no doubt these events will have massive implications for the future state of the supply chain and security.

Current State of Open Source Software

When it comes to Open Source Software, everyone (seemingly) benefits. Technologists get to work on passion projects that they get to control, while also gaining status if it becomes widely used. Hobbyists gain access to code that they might not be able to write themselves, and get to learn from the best in the industry. And for corporations, they get to use (mostly) reliable and tested code for free, saving them considerable time and money.

As such, OSS has become integral to the development process for organizations, allowing development teams to push products to market faster. These days, vendors are releasing products that contain hundreds or even thousands of open source components, and nearly all of them are needed to function properly. This practice has gone on for decades, which has made nearly every industry reliant on OSS code and dependencies – creating tons of security concerns.

You Are What You Eat

There are risks when using OSS. For starters, many vendors and organizations aren’t keeping track of which OSS components are being used in their products. Indiscriminate consumption of OSS can lead to possible lawsuits if organizations unknowingly use licensed code. But more importantly, not knowing which libraries are bundled makes it near impossible to keep them up-to-date, or to detect the vulnerabilities inside of them.

Products can inherit vulnerabilities contained in OSS code and if exploited, these issues can give malicious actors an open door into even the largest organizations. In addition to vulnerabilities, other third-parties could attempt to add malicious updates, or try to typo-squat – tricking organizations to download fake versions of popular libraries.

Understanding Node-ipc

Node-ipc stands out from the usual risks associated with OSS. Since RIAEvangelist repurposed his own code, his decision to overwrite Russian and Belarusian machines may not fully constitute a “vulnerability”. Even though it did tamper with the integrity of those machine’s systems, it wasn’t a flaw. Overwriting code was its intended purpose and it performed its task.

To fully understand this, it is important to have a grasp of all of the released versions of Node-ipc as there is some confusion as to what each does. Here is an overview of its released versions:

  • Version 10.1.1 (Released March 7, 2022)
    This version contained code that checked if the host had an IP address believed to be in Russia or Belarus. If it did, node-ipc would overwrite as many files as it could with a “heart” symbol. This behavior was not documented in its README file.
  • Version 10.1.2 (Released March 7, 2022)
    Reported to function similarly as version 10.1.1.
  • Version 10.1.3 (Released March 8, 2022)
    This version functioned as intended and did not overwrite code. It also did not contain the ‘peacenotwar’ package, mentioned below.
  • Version 11 (Released March 8, 2022)
    This version contains the package ‘peacenotwar’ which leaves a .txt file on devices saying “war is not the answer, no matter how bad it is.
  • Version 9.2.2 (Released March 15, 2022)
    Patch version that adds ‘peacenotwar’ as a dependency. It also changed the license from MIT to DBAD.

In terms of tampering, two things occurred. One was the overwriting of code and the second is the ‘peacenotwar’ package.


‘Peacenotwar’ leaves a .txt file on impacted machines with the following message:

War is not the answer, no matter how bad it is. Please stand up against this injustice and stand up against evil. Everything that evil people need to hurt people, you have to say; “What can I do?” You are one person. It’s powerful. When one person is standing next to another and they are standing next to another, you soon have movement. Here’s how little people can come together for more than one person. Do what you think is right, follow your own morals.”

Brandon Nozaki Miller (RIAEvangelist), author of Node-ipc

A Community Split in Two

RIAEvangelist’s decision to use his code as a protest has created a massive split in the Open Source community. Was RIAEvanglist’s actions malicious? Depending on who you ask, some might say that there was nothing wrong about his intentions:

Some like the GitHub user above, as well as RIAEvangelist himself, stand by his decision. However, the opinion that most in the community have is that his actions are a massive blow to the credibility and trust of OSS:

A few have also come forward claiming that RIAEvangelist’s actions have had direct consequences on their businesses. On March 17, a user claiming to represent an American Non-Government Organization stated that Node-ipc allegedly wiped over 30,000 of their messages and files detailing Russian war crimes committed against Ukraine.

While the authenticity of this claim is disputed, it does highlight that IP-based attribution is not reliable. Just because a machine’s IP is located in a certain country, it doesn’t mean that it is directly controlled by them. Initiating malware by country code could do more harm than good, impacting Russian or Belarusian organizations that are fully and publicly against the war.

The Purpose of Open Source Software

The Open Source community was formed on the ideals of improving software, skills, and empowering change. By that definition, you can argue that RIAEvangelist is pushing for change. Although, at the same time the community does not tolerate bad actors. Supporting Ukraine is the right thing to do. But at the end of the day, does Node-ipc’s changes fulfill the other ideals that led to the creation of the Open Source community? That is up to the community to decide.

The Node-ipc event has led to the coining of “protestware” and its aftermath may inspire other developers to follow suit. Russia’s largest bank in particular is wary of this as they have advised their customers to avoid updating computer programs, or insisting them to manually check the source code of any open source project.

If this trend continues it can lead to a slippery slope as OSS is supposed to help. Nearly every industry has adopted technology so therefore, the foundations of countless organizations’ systems and products run on OSS. If other authors, owners, and maintainers choose to morph their projects into protestware there is a high chance that many organizations will become collateral damage. And if people cannot trust Open Source, then theoretically the community could fall apart.

The Future State of OSS Security

If situations like the Node-ipc incident were to become common, organizations would have three options:

  1. Simply accept current risk and operate as they are
  2. Adopt certain OSS libraries and maintain it moving forward
  3. Forego OSS entirely and write their own code

1. Operate as Normal, Accepting Possible Risk

By and large, this is the current state of Open Source security, and if you want proof, you’d only have to look at  struts-shock, heartbleed, and log4shell. All of these were OSS vulnerabilities that had major impacts on organizations. And despite some of these issues existing for years, undiscovered in open code, most organizations still choose to indiscriminately consume open source components.

Enterprises should at least create a Software Bill of Materials (SBOM) to keep tabs on the various OSS components being used in their deployed software. Doing this will help their security teams track vulnerabilities affecting third-party libraries and dependencies. It can also help prevent developers falling for typo-squatting attempts.

However this won’t do much in situations in which the perpetrator is the author, owner, or maintainer for a third-party library. There are a few examples of where authors delete or sabotage their own code due to burnout or being wronged in some way. And when this happens, it can create chaos potentially giving malicious actors an opportunity to capitalize.

2. Adopt OSS Libraries and Self-Maintain

To lessen the impact that one developer can have, organizations may want to consider forking the OSS libraries they use and maintain them internally moving forward. Although this is likely the best option in some cases, it will require a SBOM and a significant amount of resources.

One product often contains hundreds of bundled libraries so depending on how much software is deployed, this will likely be an incredible undertaking. There are few organizations that can dedicate personnel to accomplish this and even if they tried, there are too many libraries for one team to track and monitor. If some organizations are having trouble checking release notes, it is very likely that they will not be able to take the time to audit newly released code.

3. Write Code Themselves

This method requires the most time and resources and will likely never happen for many organizations. There is a reason why organizations choose to use OSS for their products. Production cycles have become incredibly short and are very demanding. Adding more custom code that performs critical functionality makes this more difficult. As such, reliance on OSS will never cease.

Take Control by Understanding Cost of Ownership

Maybe Node-ipc will be the watershed moment that makes organizations realize the risks that OSS can introduce. That is uncertain, but what is certain is that the work done by technologists often goes unthanked. Whenever issues go wrong with third-party libraries and dependencies, those who aren’t in the know tend to place the blame directly on the project.

We don’t often think about the scope of most OSS projects. According to a report, many of the top 500 most used free and open-source software projects are listed under a single developer’s personal account. Most OSS is written and maintained by one or a small group of enthusiasts in their spare time, so is it fair to hold them accountable for the security of thousands of organizations? These are usually unpaid, passion projects and if things go wrong they have to fix it off the clock.

Like CVE wasn’t intended to be the vulnerability bible, OSS software wasn’t supposed to be massively consumed by corporations. To avoid the ramifications of a developer going rogue, organizations should take ownership of their own security. And to do that, they will need to take SBOMs seriously and use quality vulnerability intelligence to understand the cost of ownership for the products they deploy.

Our products
The Platform
Risk Based Intelligence
Learn more
Vulnerability Intelligence
Learn more
Cyber Risk Analytics
Threat Intelligence
Learn more
Risk Management
Learn more