The promise of open source code and the paradox of “ProtestWare”

0

The Free Software (OSS) community was split in two after a OSS author repurposed his own library to protest against the Ukrainian-Russian war. On March 7, RIAEvangelist has released several versions of its “node-ipc” software package – which has been downloaded millions of times— with some versions that would overwrite the code on machines presumably located in Russia and Belarus.

Approximately one module, called peacenotwarRIAEvangallist, wrote:

This code serves as a non-destructive example of the importance of controlling your node modules. It also serves as a non-violent protest against the Russian aggression that threatens the world right now. This module will add a message of peace to your users’ desktops, and it will only do so if it doesn’t already exist just to be polite.

His actions – i.e. “deliberately sabotaging his own code” – sparked enormous controversy while spawning a new wave of “protest softwarewhere other hacktivist developers can target Russian-based machines.

the The Open Source Community Formed on the ideals of improving software, skills and empowering change. By this definition, you can say that RIAEvangelist, whose first name is Brandon Nozaki Miller, drives change. At the same time, however, the the community does not tolerate bad actors. Do the node-ipc changes fulfill or neglect the ideals that led to the creation of the Open Source community? That’s up to the community to decide.

Potential fallout from protest software

The node-ipc event led to the creation of “protestware” and its aftermath may inspire other developers to follow suit. Russia’s largest bank in particular is wary of this because it has advised his clients to avoid updating computer programs or insisting that they manually check the source code of any open source project.

If this trend continues, it may lead to a slippery slope as the OSS is supposed to help. Almost every industry has embraced the technology. As a result, the foundations of countless organizations’ systems and products run on OSS. If other authors, owners, and maintainers choose to turn their projects into protest software, chances are that many organizations will become collateral damage. And if people can’t trust Open Source, then theoretically the community could collapse.

Were RIAEvanglist’s actions malicious? Depending on who you ask, some might say there was nothing wrong with his intentions:

Some like the GitHub user above, as well as RIAEvangelist himself, stick to his decision. However, the opinion that most members of the community hold is that his actions are a serious blow to the credibility and trust of the OSS:

A few have also come forward claiming that RIAEvangelist’s actions have directly impacted their businesses. On March 17, an Internet user claiming to represent a American non-governmental organization said node-ipc would have erased 30,000 of their messages and files detailing Russian war crimes committed against Ukraine.

Although the authenticity of this claim is disputed, it highlights that attribution based on intellectual property is unreliable. Just because a machine’s IP address is located in a certain country doesn’t mean it’s directly controlled by them. Launching malware by country code could do more harm than good, impacting Russian or Belarusian organizations that are fully and publicly against the war.

Current state of open source software

When it comes to Open Source software, everyone (apparently) benefits from it. Technologists work on passion projects that they control, while gaining status if they become widely used. Hobbyists have access to code they may not be able to write themselves and learn from the best in the industry. And for companies, they can use (mostly) reliable and tested code for free, which saves them considerable time and money.

As such, OSS has become an integral part of organizations’ development process, enabling development teams to bring products to market faster. These days, vendors release products that contain hundreds, if not thousands, of open source components, and almost all of them are required to function properly. This practice has been going on for decades, which has made almost every industry dependent on OSS code and dependencies, creating tons of security issues.

You are what you consume

There are risks when using OSS. For starters, many vendors and organizations don’t keep track of the OSS components used in their products. Indiscriminate consumption of OSS can result in possible legal action if organizations unknowingly use licensed code. But more importantly, not knowing which libraries are bundled together makes it nearly impossible to keep them up to date or detect vulnerabilities within them.

Products can inherit vulnerabilities in OSS code, and if exploited, these issues can give malicious actors an open door in even the largest organizations. In addition to the vulnerabilities, other third parties might try to add malicious updates or try typo squatting to trick organizations into downloading bogus versions of popular libraries.

Understanding node-ipc

In terms of tampering, node-ipc did two things. The first is to overwrite the code of Russian and Belarusian machines, and the second is the “peacenotwar” package. For detailed information on each version, see Original post from Risk Based Security. However, the most important conclusion is that current versions of node-ipc do not overwrite code.

What organizations can do for OSS security

Should situations like the Node-ipc incident become commonplace, organizations would have three options:

  • Simply accept the current risks and act as they are
  • Adopt some OSS libraries and maintain them in the future
  • Forgo OSS entirely and write your own code

1. Operate normally, accepting the possible risks

All in all, this is the current state of Open Source security, and if you want proof, just look. shock struts, bleeding heartand log4shell. All of these OSS vulnerabilities have had major impacts on organizations. And despite some of these issues that have existed for years and gone undiscovered in open code, most organizations still choose to indiscriminately consume open source components.

Companies should at least create a Software nomenclature (SBOM) to keep an eye on the various OSS components used in their deployed software. This will help their security teams track vulnerabilities affecting third-party libraries and dependencies. It can also help prevent developers from falling into typosquatting attempts.

However, this won’t do much in situations where the author is the author, owner, or maintainer of a third-party library. There are a few examples of authors removing or sabotaging their own code due to burnout or to be harmed in one way or another. And when that happens, it can create chaos potentially give malicious actors an opportunity to capitalize.

2. Embrace OSS Libraries and Self-Sustain

To mitigate the impact a developer may have, organizations may consider forking the OSS libraries they use and maintaining them in-house going forward. Although this is probably the best option in some cases, it will require an SBOM and a significant amount of resources.

A product often contains hundreds of libraries bundled together, so depending on the amount of software deployed, it’s likely to be an amazing undertaking. There are few organizations that can dedicate staff to accomplish this and even if they tried, there are too many libraries for a single team to track and monitor. If some organizations are having trouble verifying the release notes, it’s very likely that they won’t be able to take the time to audit newly released code.

3. Write code independently

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

Take control by understanding the cost of ownership

Node-ipc may be the watershed moment that will make organizations aware of the risks that OSS can introduce. It is uncertain, but what is certain is that the work done by technologists is often thankless. Whenever issues arise with third-party libraries and dependencies, those who aren’t aware tend to blame the project directly.

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

As CVE wasn’t meant to be the bible of vulnerabilities, OSS software was not meant to be massively consumed by enterprises. To avoid the ramifications of a dishonest developer, organizations must take ownership of their own security. And to do that, they will need to take SBOMs seriously and use quality vulnerability information to understand the cost of ownership of the products they deploy.

In order to detect risks in open source software and its dependencies, organizations need quality vulnerability information. Flashpoint tracks and monitors thousands of third-party libraries. Sign up for a free try and learn more today.

Share.

Comments are closed.