faker.js and colors.js have been corrupted by their devloper

Open source developer corrupts widely used libraries, affecting tons of projects

software Jan 10, 2022

He pushed corrupt updates that trigger an infinite loop

Illustration by Alex Castro / The Verge

A developer appears to have purposefully corrupted a pair of open-source libraries on GitHub and software registry npm — “faker.js” and “colors.js” — that thousands of users depend on, rendering any project that contains these libraries useless, as reported by Bleeping Computer. While it looks like color.js has been updated to a working version, faker.js still appears to be affected, but the issue can be worked around by downgrading to a previous version (5.5.3).

THE SABOTAGED VERSIONS CAUSE APPLICATIONS TO INFINITELY OUTPUT STRANGE LETTERS AND SYMBOLS

Bleeping Computer found that the developer of these two libraries, Marak Squires, introduced a malignant commit (a file revision on GitHub) to colors.js that adds “a new American flag module,” as well as rolled out version 6.6.6 of faker.js, triggering the same destructive turn of events. The sabotaged versions cause applications to infinitely output strange letters and symbols, beginning with three lines of text that read “LIBERTY LIBERTY LIBERTY.”

Even more curiously, the faker.js Readme file has also been changed to “What really happened with Aaron Swartz?” Swartz was a prominent developer who helped establish Creative Commons, RSS, and Reddit. In 2011, Swartz was charged for stealing documents from the academic database JSTOR with the purpose of making them free to access, and later committed suicide in 2013. Squires’ mention of Swartz could potentially refer to conspiracy theories surrounding his death.

As pointed out by Bleeping Computer, a number of users — including some working with Amazon’s Cloud Development Kit — turned to GitHub’s bug tracking system to voice their concerns about the issue. And since faker.js sees nearly 2.5 million weekly downloads on npm, and color.js gets about 22.4 million downloads per week, the effects of the corruption are likely far-reaching. For context, faker.js generates fake data for demos, color.js adds colors to javascript consoles.

In response to the problem, Squires posted an update on GitHub to address the “zalgo issue,” which refers to the glitchy text that the corrupt files produce. “It’s come to our attention that there is a zalgo bug in the v1.4.44-liberty-2 release of colors,” Squires writes in a presumably sarcastic way. “Please know we are working right now to fix the situation and will have a resolution shortly.”

Two days after pushing the corrupt update to faker.js, Squires later sent out a tweet noting he’s been suspended from GitHub, despite storing hundreds of projects on the site. Judging by the changelog on both faker.js and colors.js, however, it looks like his suspension has already been lifted. Squires introduced the faker.js commit on January 4th, got banned on January 6th, and didn’t introduce the “liberty” version of colors.js until January 7th. It’s unclear whether Squires’ account has been banned again. The Verge reached out to GitHub with a request for comment but didn’t immediately hear back.

The story doesn’t end there, though. Bleeping Computer dug up one of Squires’ posts on GitHub from November 2020, in which he declares he no longer wants to do free work. “Respectfully, I am no longer going to support Fortune 500s (and other smaller sized companies) with my free work,” he says. “Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.”

Squires’ bold move draws attention to the moral — and financial — dilemma of open-source development, which was likely the goal of his actions. A massive number of websites, software, and apps rely on open-source developers to create essential tools and components — all for free. It’s the same issue that results in unpaid developers working tirelessly to fix the security issues in their open-source software, like the Heartbleed scare in 2014 that affected OpenSSL and the more recent Log4Shell vulnerability found in log4j that left volunteers scrambling to fix.

By Emma Roth

CONTINUED:

Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps

Users of popular open-source libraries 'colors' and 'faker' were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.

Some surmised if the NPM libraries had been compromised, but it turns out there's much more to the story.

The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on 'colors and 'faker'.

The colors library receives over 20 million weekly downloads on npm alone, and has almost 19,000 projects depending on it. Whereas, faker receives over 2.8 million weekly downloads on npm, and has over 2,500 dependents.

Open Source Revolution?

The developer behind popular open-source NPM libraries 'colors' (aka colors.js on GitHub) and 'faker' (aka 'faker.js' on GitHub) intentionally introduced mischievous commits in them that are impacting thousands of applications relying on these libraries.

Yesterday, users of popular open-source projects, such as Amazon's Cloud Development Kit (aws-cdk) were left stunned on seeing their applications print gibberish messages on their console.

These messages included the text 'LIBERTY LIBERTY LIBERTY' followed by a sequence of non-ASCII characters:

Users left stunned on seeing garbage data printed by 'faker' and 'colors' projects (GitHub)

Initially, users suspected that the libraries 'colors' and 'faker' used by these projects were compromised [1, 2, 3], similar to how coa, rc, and ua-parser-js libraries were hijacked last year by malicious actors.

But, in fact, it was the dev behind colors and faker who appears to have intentionally committed the code responsible for the major blunder, as seen by BleepingComputer.

The developer, named Marak Squires added a "new American flag module" to colors.js library yesterday in version v1.4.44-liberty-2 that he then pushed to GitHub and npm.

colors.js mischievous commit made by 'Marak' (GitHub)

The infinite loop introduced in the code will keep running indefinitely; printing the gibberish non-ASCII character sequence endlessly on the console for any applications that use 'colors.'

Likewise, a sabotaged version '6.6.6' of faker was published to GitHub and npm.

"It's come to our attention that there is a zalgo bug in the v1.4.44-liberty-2 release of colors," mocked the developer.

"Please know we are working right now to fix the situation and will have a resolution shortly."

Zalgo text refers to certain non-ASCII characters that appear glitchy.

The reason behind this mischief on the developer's part appears to be retaliation—against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community.

In November 2020, Marak had warned that he will no longer be supporting the big corporations with his "free work" and that commercial entities should consider either forking the projects or compensating the dev with a yearly "six figure" salary.

"Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work. There isn't much else to say," the developer previously wrote.

"Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.

Interestingly, as of today, BleepingComputer noticed that the README page for the 'faker' GitHub repo was also modified by the developer to make reference to Aaron Swartz by stating: "What really happened with Aaron Swartz?"

Swartz was an American programmer, entrepreneur, and renowned hacktivist who, following a legal battle, committed suicide.

In an effort to make information freely accessible to all, the hacktivist downloaded millions of journal articles from the JSTOR database present on the MIT campus network, allegedly by rotating his IP and MAC addresses repeatedly to get around the technological blocks put in place by JSTOR and MIT.

In the process of doing this, Swartz may have run afoul of the Computer Fraud and Abuse Act and faced criminal charges, with penalties of up to thirty-five years in prison.

Uncanny can of worms

Marak's bold move has opened up a can of worms and attracted mixed responses.

Some members of the open-source software community have praised the developer's actions, while others are appalled by it.

"Apparently the author of 'colors.js' is angry for not being payed... So he decided to print the American flag each time his library is loaded... WTF," tweeted one user.

Some dubbed this an instance of "yet another OSS developer going rogue," whereas InfoSec expert VessOnSecurity called the action "irresponsible," stating:

"If you have problems with business using your free code for free, don't publish free code. By sabotaging your own widely used stuff, you hurt not only big business but anyone using it. This trains people not to update, 'coz stuff might break."

GitHub has reportedly suspended the developer's account. And, that too, has caused mixed reactions

"Removing your own code from [GitHub] is a violation of their Terms of Service? WTF? This is a kidnapping. We need to start decentralizing the hosting of free software source code," responded software engineer Sergio Gómez.

"Never know what happened but I’m hosting all of my projects on GitLab private instance just in cause things like this happening to me. Never trust any internet service provider," tweeted another.

"Marak yeeted faker and colors, bricking tons of projects, and expected nothing to happen?" stated a developer named Piero.

Note, Marak's surprising move follows the recent Log4j debacle that set the internet on fire.

Open-source library Log4j is used extensively in a vast range of Java applications, including those developed by corporations and commercial entities.

But, shortly after mass-exploitation of the Log4shell vulnerability, the maintainers of the open-source library worked without compensation over the holidays to patch the project, as more and more CVEs were being discovered.

Concerns followed as to how big businesses were used to "exploiting" open-source; by consuming it incessantly but not giving back enough to support the unpaid volunteers who sustain these critical projects by giving up their free time.

Some also criticized the netizens and bug bounty hunters hounding the Log4j maintainers who were already "working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc." [1, 2, 3].

"The responses to the colors.js/faker.js author sabotaging their own packages are really telling about how many corporate developers think they are morally entitled to open source developers' unpaid labour without contributing anything back," wrote one Twitter user.

Time will tell what the future of open-source software entails, with regards to the OSS sustainability problem.

In the meantime, users of 'colors' and 'faker' NPM projects should ensure they are not using an unsafe version. Downgrading to an earlier version of colors (e.g. 1.4.0) and faker (e.g. 5.5.3) is one solution.

Update 10:08 AM ET: Added tweet from @VessOnSecurity after publishing.

Update 11:24 AM ET: Added developer's full name, Marak Squires.

By Ax Sharma

CONTINUED:

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

On January 8th, 2022, 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 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.

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:

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)
}

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 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. Using services such as Snyk to prevent malicious packages and supply chain attacks

By Liran Tal

Open source developer corrupts widely used libraries
Open source developer corrupts widely used libraries, affecting tons of projects He pushed corrupt updates that trigger an infinite loop A developer appe...
Discuss on the forum

Tags