I wanted to document (mainly for myself) the emerging trend of "hacktivism" in the world of open-source, its impact on fellow developers, and the response of the broader community.
I'll keep updating this document as the events unfold.
(2016) left-pad
It all started with the NPM library left-pad
in 2016,
when its developer decided to remove his libraries from NPM
in protest to a company that sent its lawyers to pressure the developer in renaming one of his libraries,
and as a consequence NPM unilaterally enforced the renaming without the developer's consent.
Because it was a widely used dependency in many other libraries, it had a major impact across the development world by having broken builds and installs.
Everything was resolved, again unilaterally, by NPM when they've republished the library, again without the developer's consent, granted due to the fact that the library was under an open-source license.
- [developer post] I’ve Just Liberated My Modules
- [theregister.com] How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript
(2022) colors and faker
Then in early 2022 it followed with two other NPM libraries colors
and faker
,
when their developer wanted to protest against large corporations
that used his (and others) open-source code and never contributing back
(neither with code nor with financial support).
Again, being two popular libraries, it had a major impact in the development world, but this time it didn't manifest in broken builds, instead the software entered an infinite loop, and displayed random characters on the console.
It was the first well-known instance when a developer adds malicious code. However, the effects were benign this time...
It was again solved by downgrading the NPM libraries to previous working versions.
- [bleepingcomputer.com] Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps
- [Russ Cox] What NPM Should Do Today To Stop A New Colors Attack Tomorrow
(2022) node-ipc
Not much later, still in 2022, the world caught on fire when Russia decided to invade Ukraine, and developers decided to join the war efforts how they knew best -- some created sites to help refugees, some engaged in DDoS attacks against russian sites, while others decided to weaponize their open-source code targeting russians and belarusians developers and users.
One such "protestware" (as its category was coined) is another NPM library node-ipc
,
whose developer decided it was a good idea to introduce some obfuscated code
that when run it tried to geolocate the host IP, and if it found it to be from Russia or Belarus,
it started shredding any file it could have access to...
Thankfully, the affected versions were quickly removed from the NPM registry, however there are accounts of actual data being lost.
Obviously, this has gotten a "little" more attention than the previous cases, including responses from EFF and OSI.
- [snyk.io] Alert: peacenotwar module sabotages npm developers in the node-ipc package to protest the invasion of Ukraine
- [snyk.io] Protestware is trending in open source: 4 different types and their impact
- [krebsonsecurity.com] Pro-Ukraine 'Protestware' Pushes Antiwar Ads, Geo-Targeted Malware
- [eff.org] Anti-War Hacktivism is Leading to Digital Xenophobia and a More Hostile Internet
- [opensource.org] Open source 'protestware' harms Open Source
- [wired.com] The Fragile Open Source Ecosystem Isn't Ready for 'Protestware'
- [arstechnica.com] Protestware Comes of Age -- Sabotage: Code added to popular NPM package wiped files in Russia and Belarus
- [internet] On the importance of trusting trust
- [github.com/advisories] Embedded Malicious Code in node-ipc
- CVE-2022-23812
Observations
As one commenter noted, "the Pandora's box has been open"...
Is it a coincidence that all of the above are NodeJS / NPM libraries? All this "protestware" could have been written in any language, from C to Go and Rust. But apparently the problem has so far struck only the JavaScript ecosystem.
What would have been the impact of these issues, if NPM hadn't existed? Say the libraries in question would have been written in PHP, and their distribution would have been "manual" by downloading and unzipping archives...
How could developers protect themselves from future similar issues? One possibility is having "burner accounts", or even better "burner laptops", where all the development happens... But then, how about when we get to production?