Chances are unless you’re a JavaScript programmer, you’ve never heard of the open-source Javascript libraries ‘colors.js’ and ‘faker.js.” They’re simple programs that respectively let you use colored text on your node.js, a popular JavaScript runtime, console, and create fake data for testing. Faker.js is used with more than 2,500 other Node Package Manager (NPM) programs and is downloaded 2.4 million times per week. Colors.js is built into almost 19,000 other NPM packages and is downloaded 23 million times a week. In short, they’re everywhere. And, when their creator, JavaScript developer Marak Squires, fouled them up, tens of thousands of JavaScript programs blew up.
Thanks, guy.
This isn’t the first time a developer deliberately sabotaged their own open-source code. Back in 2016, Azer Koçulu deleted a 17-line npm package called ‘left-pad, ‘which killed thousands of Node.js programs that relied on it to function. Both then and now the actual code was trivial, but because it’s used in so many other programs its effects were far greater than users would ever have expected.
Why did Squires do it? We don’t really know. In faker.js’s GitHub README file, Squires said, “What really happened with Aaron Swartz?” This is a reference to hacker activist Aaron Swartz who committed suicide in 2013 when he faced criminal charges for allegedly trying to make MIT academic journal articles public.
Your guess is as good as mine as to what this has to do with anything.
What’s more likely to be the reason behind his putting an infinite loop into his libraries is that he wanted money. In a since-deleted GitHub post, Squires said, “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. Take this as an opportunity to send me a six-figure yearly contract or fork the project and have someone else work on it.”
Excuse me. While open-source developers should be fairly compensated for their work, wrecking your code isn’t the way to persuade others to pay you.
This is a black eye for open-source and its developers. We don’t need programmers who crap on their work when they’re ticked off at the world.
Another problem behind the problem is that too many developers simply automatically download and deploy code without ever looking at it. This kind of deliberate blindness is just asking for trouble.
Just because a software package was made by an open-source programmer doesn’t mean that it’s flawless. Open-source developers make as many mistakes as any other kind of programmer. It’s just that in open source’s case, you have the opportunity to check it out first for problems. If you choose to not look before you deploy, what happens next is on you.
Some criminal developers are already using people’s blind trust to sneak malware into their programs. For example, the DevOps security firm JFrog recently discovered 17 new JavaScript malicious packages in the NPM repository that deliberately attack and steal a user’s Discord tokens. These can then be used on the Discord communications and digital distribution platform.
Is that a lot of work? You bet it is. But, there are tools such as NPM audit, GitHub’s DependendaBot, and OWASP Dependency-Check that can help make it easier.
In addition, you can simply make sure that before any code goes into production, you simply run a sanity check on it in your continuous integration/continuous distribution (CI/CD) before deploying it to production.
I mean, seriously, if you’d simply run either of these libraries in the lab they would have blown up during testing and never, ever make it into the real world. It’s not that hard!
In the meantime, GitHub suggests you revert back to older, safer versions. To be exact, that’s colors.js 1.40 and faker.js 5.5.3.
As CodeNotary, a software supply chain company, pointed out in a recent blog post, “Software is never complete and the code base including its dependencies is an always updating document. That automatically means you need to track it, good and bad, keeping in mind that something good can turn bad.” Exactly!
Therefore, they continued, “The only real solution here is to be on top of the dependency usage and deployment. Software Bill of Materials (SBOMs) can be a solution to that issue, but they need to be tamper-proof, queryable in a fast and scalable manner, and versioned.
CodeNotary suggests, of course, you use their software, Codenotary Cloud and the vcn command-line tool, for this job. There are other companies and projects that address SBOM as well. If you want to stay safe, moving forward you must — I repeat must — use an SBOM. Supply chain attacks, both from within projects and without, are rapidly becoming one of the main security problems of our day.
Related Stories:
