The Promise of Open Source Code and the Paradox of ProtestWare – Security Boulevard

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 packagewhich has been downloaded millions of timeswith some versions reportedly overwriting code on machines presumably located in Russia and Belarus.

About one module, called peacenotwar, RIAEvangallist, wrote:

This code serves as a non-destructive example of why controlling your node modules is important. It also serves as a non-violent protest against Russias aggression that threatens the world right now. This module will add a message of peace on your users desktops, and it will only do it if it does not already exist just to be polite.

His actionsi.e. deliberately sabotaging his own codehave sparked a massive controversy while giving birth to a new surge of protestware, where other hacktivist developers may target Russian-based machines.

The Open Source community was formed on the ideals of improving software, skills, and empowering change. By that definition, you can argue that RIAEvangelist, whose given name is Brandon Nozaki Miller, is pushing for change. At the same time, however, the community does not tolerate bad actors. Does node-ipcs changes fulfill or neglect the 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. Russias largest bank in particular is wary of this as they have advised its 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.

Were RIAEvanglists 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 RIAEvangelists 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 machines IP is located in a certain country, it doesnt 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.

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 dependenciescreating tons of security concerns.

There are risks when using OSS. For starters, many vendors and organizations arent 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-squattricking organizations to download fake versions of popular libraries.

In terms of tampering, node-ipc did two things. The first is overwriting code for Russian and Belarus-based machines, and the second is the peacenotwar package. For detailed information on each version, check out Risk Based Securitys original post. However, the most important takeaway is that current versions of node-ipc do not overwrite code.

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

By and large, this is the current state of Open Source security, and if you want proof, youd 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 wont 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.

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.

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.

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 arent in the know tend to place the blame directly on the project.

We dont 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 developers 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 wasnt intended to be the vulnerability bible, OSS software wasnt 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.

In order to detect risk in Open Source Software and dependencies, organizations need quality vulnerability intelligence. Flashpoint tracks and monitors thousands of third-party libraries. Sign up for a free trialand learn more today.

The post The Promise of Open Source Code and the Paradox of ProtestWare appeared first on Flashpoint.

*** This is a Security Bloggers Network syndicated blog from Blog Flashpoint authored by Jonathan Zalman. Read the original post at: https://www.flashpoint-intel.com/blog/the-promise-of-open-source-code-and-the-paradox-of-protestware/

Continue reading here:
The Promise of Open Source Code and the Paradox of ProtestWare - Security Boulevard