An astonishing incident in recent days highlights the risks of widespread dependence on open source software – while also highlighting the free labor corporations benefit from by using open source software.
Marak Squires, an open source coder and maintainer, sabotaged his repository to protest against unpaid work and his failed attempts to monetize faker.js and color.js, two major NPM packages used by a huge range of other packages and projects.
The software industry relies on various interdependent ecosystems and resources. This incident shows a well-known and unsolved issue for the software supply chain: the “dependency hell.” It’s especially true in the world of Nodes.js and JavaScript, but it’s also a common concern with open source software in general.
Hackers try to infect legitimate apps during a supply chain attack to distribute malware. In the case of faker.js and color.js, we have a pretty rare variant that leverages the highest privileged access.
See also: Open Source Security: A Big Problem
Popular NPM Packages Corrupted by Author
NPM is the package manager for Node.js. It’s the world’s largest software registry, with hundreds of thousands of packages.
It’s free to use, and you don’t even need to register or log in to download tons of third-party scripts and libraries.
Colors is a pretty popular package, with millions of downloads, and is used by JavaScript and Node.js developers to get custom colors and styles in their console. According to GitHub, 4.3 million projects were using it, which includes many other popular packages.
As a result, new releases are downloaded by myriad installations as soon as they are available, making the package quite essential in the supply chain.
Just days earlier, Squires “ended” another well known repository (used by 168,000 projects) called faker.js with an explicit commit message: endgame.
The main files have disappeared; only some configurations remain.
Squires posted the following on his GitHub repository:
“It’s come to our attention that there is a zalgo bug in the v1.4.44-liberty-2 release of colors.”
The name of the branch merged in the core was odd and the associated commit named “fix bug” contained malicious instructions to trigger an infinite loop:
for (let i = 666; i < Infinity; i++) { if (i % 333) { // console.log('testing'.zalgo.rainbow) } console.log('testing testing testing testing testing testing testing'.zalgo) }
The above code is located in the index.js file, which runs automatically when the library is used. Zalgo text refers to special non-ASCII characters that don’t render as expected and trigger UI glitches.
When executed, the code never stops. It’s a logic issue known as an “infinite loop.” Everything from the integer used to initialize the loop (666) to the limit fixed by the author (Infinity) suggests it was intentional.
At first sight, it looks like a joke for anyone that has ever played with JavaScript, but there were consequences for projects that rely on this famous library, breaking many CI/CD pipelines and terminal prompts:
Squires is not the only maintainer of the repository, but he revoked other maintainers’ access to make sure nobody could revert his action. A message he subsequently posted on Twitter sparked significant debate about the open source model, with some sympathizing and others saying the open source agreement was always clear.
Users could potentially revert to previous versions of the software, which seems easier in the case of colors. The faker.js page appears to have been thoroughly wiped, but there’s always archive.org as a possible solution. Such a fix should only be temporary, though, as these repositories cannot be trusted anymore. There are alternative packages, and in the case of faker, an alternative has already emerged.
Github has issued an advisory in the case of colors.
See also: Top Code Debugging and Code Security Tools
The State of Open Source
On his blog, the developer said no company has supported faker.js and color.js financially. He received only a few donations via GitHub Sponsorships, and the donors were fellow developers.
He tried to monetize his code by starting a cloud service with monthly subscription plans, but did not reach enough users he claimed one of his GitHub sponsors (also appearing to be a registered subscriber) coopted his idea to launch the same offer.
An open-source dead end is not completely uncommon and can lead to extreme reactions in worst-case scenarios, such as what Squires did with his repositories.
It could potentially inspire more open-source maintainers and even become a trend if no one finds sustainable economic models, especially when many private and profit organizations use or fork public resources.
Even if GitHub and NPM have reacted quickly, removing the packages and temporarily suspending the author’s account, the damage has been done.
Developers should prepare for such incidents with better dependency management.
How to Mitigate Dependency Incidents
While you cannot anticipate such radical actions, you may be able to improve your preparation. There are open-source security best practices you can apply to mitigate incidents, such as:
- Testing before deploying anything on a remote environment
- Locking fixed versions: in the package.json file that lists packages, don’t use symbols such as “^” or “~” for dependencies, as it’s more permissive and allows automatic minor (or bigger) updates when you run an npm update
- Being extra vigilant with misspelled packages to prevent typosquatting attacks
Further reading: Top Vulnerability Management Tools