Open source maintainer pulls the plug on npm packages colors and faker, now what?

On January 8, 2022, the open source maintainer of the wildly popular npm package colors, published colors@1.4.1 and colors@1.4.44-liberty-2 in which they intentionally introduced an offending commit that adds an infinite loop to the source code. The infinite loop is triggered and executed immediately upon initialization of the package’s source code, and would result in a Denial of Service (DoS) to any Node.js server using it.

TL;DR: Snyk issued a Denial of Service security vulnerability for colors@1.4.1, following this vulnerable code. We highly recommend you revert to colors@1.4.0, and pin your dependencies’ versions to avoid blind upgrades of the offending version. We also recommend you migrate to a different package. Continue reading for more information on scope, impact, and recommended counter-measures.

About colors

The colors open source npm package receives over 20 million downloads a week and is a key ecosystem project with JavaScript and Node.js developers, powering a great set of projects. GitHub records show that the colors project is used within more than 4 million other projects, and npmjs.org shows this npm package is dependent upon by 18,962 other packages.

The following are a handful of projects that depend upon colors:

• The prompt command-line helper (~500,000 weekly downloads)

• Unicode table formatting cli-table3 (~7 million weekly downloads)

• AWS’s own aws-cdk (~2 million weekly downloads)

In fact, the broken colors@1.4.1 version impacts a large amount of users and is not to be taken lightly. According to the package page statistics on npmjs, we learn that this version has been downloaded 95,397 times at the time of writing this blog post:

The breaking code

The following offending code was introduced to the vulnerable colors library:

1for (let i = 666; i < Infinity; i++;) {
2   if (i % 333) {
3       // console.log('testing'.zalgo.rainbow)
4   }
5   console.log('testing testing testing testing testing testing testing'.zalgo)
6}

This infinite loop code, located in the index.js file of the package’s source code will break any usage of the package while printing some very unsettling zalgo text to the terminal:

I am dependent on this colors package, what should I do to mitigate this?

If you are currently impacted by the colors incident due to using the broken version 1.4.1, we recommend that you revert back to the latest known-good colors@1.4.0 version which doesn’t include the offending infinite loop code. For example, to pin down the stable and safe version of the colors package in your package.json file, replace the following:

1"colors":"^1.4.0"

with:

1"colors":"1.4.0"

For a future reference, we recommend the following best practices to be taken with managing open source libraries in your projects:

1. Pin your dependencies, either in your package.json or by using a lockfile. This will help you avoid install-time resolutions of newer versions, which would’ve exposed you to install the 1.4.1 patched version of colors that introduced the issue.

2. This incident should prompt you to consider moving to an alternative color handling package, such as chalk.

3. Review the maintenance and sustainability aspects of open source packages you are intending to use, and ensure they have a proper governance model, such as multiple contributors.

Faker.js: Same maintainer, same story?

This event follows a similar incident related to the popular npm package faker (known broadly as Faker.js), maintained by the same person. Faker is a project used by many developers to generative massive amounts of fake data, such that is commonly used in software testing practices.

Faker receives 2 million weekly downloads, and is also quite popular as a dependency for JavaScript and Node.js projects. However, on January 5th, 2022, the open source repository on GitHub for this package received a forced commit which completely reverted the package’s original source code:

Respectively, the faker npm package version has been promoted to 6.6.6, and published to the public npmjs registry as an empty package which contains no source code.

The maintainer created an issue stating that they will no longer maintain the package for free:

The author later removed the GitHub repository sourcing the project, likely causing a large disruption to thousands of developers using this package, now potentially seeking migration paths.

Later, they published an article regarding the matter in their personal blog, fleshing out the failed attempts at getting the project monetized or sponsored, expressing that the current state of donations is unsustainable and that "Like most of us, I have people who depend on me and I have bills to pay".

As the same maintainer takes part in about 170 other npm packages, this very well may not be the end of this story.

Dangers of open source governance and funding models

This event follows a general trend in the open source community, regarding the liability of companies and organizations that depend on open source code in production to build their products.

Following the release of the offending code in colors, the maintainer also opened a GitHub issue themselves, discussing the matter, in which they generally joke about not being able to find the cause of this “bug” and not having time to handle it.

Marak continues by tagging other highly prolific Node.js developers to help out with the matter, but none of them has real access to the project repository:

These incidents fall in line with a recent trend of discussion in the open source community, with more and more open source maintainers expressing their dissatisfaction with corporations and organizations monetizing and using open source software in their products.

Responding to open source criticism post-Log4Shell, we recently addressed maintainers' hardships in sustaining healthy open source software without funding.

We may observe a continuing trend of maintainers completely blocking off access to their packages. While the sentiment is definitely understandable and the arguments valid, it should be noted that this approach of blocking access to open source packages will also result in hurting other open source developers and maintainers.

Adopting open source security best practices

Using open source software means we need to properly assess the risks of such incidents, and other security, and legal issues, and be well prepared to handle as they unfold. Even better, if we can adopt best practices to avoid and mitigate potential supply chain security issues.

We recommend the following practices and reading content to better position yourself in future situations like this:

1. You should review the maintenance and sustainability status of open source projects. The Snyk Advisor, is such a tool that helps to gauge a package's health score.

2. 10 npm Security Best Practices mentions the importance of enabling two-factor authentication, pinning down dependencies with proper lockfile usage, and others.

3. Read up on securing your modern software supply chain with topics like dependency confusion, typosquatting and malicious packages

4. Practical advice on how Snyk helps preventing malicious packages and supply chain attacks