Protestware is trending in open source: 4 different types and their impact

A few days ago, Snyk reported on a new type of threat vector in the open source community: protestware. The advisory was about a transitive vulnerability — peacenotwar — in node-ipc that impacted the supply chain of a great deal of developers. Snyk uses various intel threat feeds and algorithms to monitor chatter on potential threats to open source, and we believe this may just be the tip of a protestware iceberg.

Since the publication of the node-ipc advisory, we’ve seen a massive spike in our dedicated alerts to threats around the conflict, and subsequently a spike in the number of different types of potential protestware relating to the invasion of Ukraine.

The current trend of protestware comes in many forms. Some of these seem to be acceptable forms of free speech, while others such as node-ipc are more destructive and damaging in nature. At Snyk, we’d like to help the community reach a consensus on how to approach the various protestware springing into existence, and help differentiate between the different types.

What is protestware?

Protestware is a catch-all term that is being used to describe packages that are altered in some way to protest against a certain event. Unlike malicious packages, these alterations are not being made by “hackers” or otherwise malicious actors, but often by known and respected members of the open source community who are active maintainers or contributors to large scale open source projects.

Before going any further, Snyk stands with Ukraine. Our stance has been made clear in our decision to donate aid to Ukraine, spotlight the amazing OSS coming out of Ukraine, and cut off business ties with Russian and Belarusian entities. Having said this, it is still our duty to report on any threats we discover in the open source community, and play our part in keeping open source safe.

In this blog we will lay out the four broad types of protestware activity we’ve encountered so far, as well as our policy in regards to each type. We hope we can use this as a springboard to further conversations on the matter in the community.

Types of protestware

1. Repo banners

In these types of packages, maintainers add political messages in “banners” in the repo itself. This looks like README files altered to express support for Ukraine, changes in the package description to support the cause, or even just open issues with an express message. From Snyk’s point of view, this level of protest sits clearly in the area of nondestructive free speech, and every maintainer and contributor has the right to express their opinion on any matter they see fit.

In cases such as this we feel quite clearly that there is no need for us to take any action.

2. CLI protest logs

The second form of protest goes one step further, and messages the protest directly on users machines within CLI logs during and post installation of the package. es5-ext is a good example of this happening in a very popular open source package and the vector we see used there is fairly indicative of these types of protestware:

1. A local machine performs a time zone check to determine the location of the machine.

2. Based on the location, a CLI log is left using post-install script with a message of support for Ukraine and information on the war as well as instructions on how to download Tor to circumvent the Russian governments’ censorship of websites with news about the war.

On examination of both these parts of the vector, our ultimate understanding is that while this is unusual behavior, it has precedent in the software ecosystem. With regards to the time zone check, local checks of a system are sometimes part of normal installation behavior, for instance to determine the best way to install a package. In terms of logging messages in the CLI during installation, there are often very robust messages logged during installation of a package, not all of which relate directly to the package install (credits, emojis, and other “soft” information is sometimes logged).

So long as the messaging remains within the installation environment (that of the CLI), we currently believe that there is no need to specifically flag these packages.

3. Out-of-env protest logs

That last distinction brings us along nicely to the third group of protestware. Packages that protest by running code outside of the installation environment. Examples of this are the event-source-pollyfill and peacenotwar packages. While both of these share the “geo-locate via time zone vector” described above, they go one step further than writing protests in logs, and actively run code on the machine to protest.

This type of protestware, whilst non-destructive, we believe creates behavior we would not expect or desire in an open source package. They might choose to spread information by creating pop-up alert windows, or by opening and redirecting browsers to websites with information, or even creating new files on the system desktop with info dumps.

For packages such as these we will be adding an advisory with the “Undesired Behavior” title. Our CVSS vectors will be built to demonstrate exactly what that undesired behavior is, and the way it impacts the integrity of the machine it runs on.

4. Destructive protests

Finally, we get to the package type that clearly displays destructive behavior and directly threatens the machines it runs on. Node-ipc is currently the biggest and most well known of these packages and, as we disclosed previously, attempts to wipe the hard drives of the system.

Packages that conduct actual damaging behavior, such as deleting files, leaking private info or anything else will be added under the title of “Malicious Package”, with a high or critical severity (depending on the specific impact of the package).

Stay alert to protestware

In summary, the current situation is a volatile one and we expect to continue to be challenged by new threat vectors around protestware going forward. We see our role here as twofold:

1. Continue to alert the community of the new threat patterns emerging as quickly and as diligently as possible.

2. To help steer the conversation around how our community should respond to protestware in all its forms, and hopefully build towards more general consensus in this matter.

If you happen to stumble across any additional protestware in open source packages, please feel free to contact us using our open source vulnerability disclosure program. Thanks for keeping open source safe for everyone to use.