You’ve probably seen the news, even if you’re not sure what happened.
Unless you’re a JavaScript programmer and you relied on either or both of a pair of modules called faker.js and colors.js.
If you were a user of either of those projects, and if you are (or were!) inclined to accept any and all updates to your source code automatically without any sort of code review or testing…
…you’re probably well aware of exactly what happened, and how it affected you.
Supply chain attacks
Long term readers of Naked Security will be familiar with the problem of so-called supply-chain attacks in open source software libraries, because we’ve written about this sort of problem in programming ecosystems before.
We’ve written about security holes suddenly showing up in numerous coding communities, including PHP programmers, Pythonistas, Ruby users, and NPM fans.
Last year, we even had reason to debate the morality of self-styled academic researchers who deliberately used the Linux kernel source code repository as a testing ground for what they unashamedly referred to as hypocrite commits.
Software supply chain attacks typically involve poisonous, dangerous or otherwise deliberately modified content that infects your network or your development team indirectly, unlike a direct hack where attackers break into your network and mount a head-on assault.
Supply chain attacks are often passed on entirely unwittingly by one of your suppliers of products and services, who may themselves have ingested the unauthorised modifcations from someone upstream of them, and so on.
LEARN MORE ABOUT SUPPLY CHAIN ATTACKS
Click-and-drag on the soundwaves below to skip to any point in the podcast.
You can also listen directly on Soundcloud, or read a complete transscript.
Unethical, perhaps, but sometimes not criminal
As we mentioned above, however, supply chain problems of this sort don’t always arise from criminal intent, even though they may ultimately be judged unethical (or infantile, or ill-thought-out, or any combination of those).
We already mentioned hypocrite commits, which were intended to remind us all that it’s possible to inject malicious backdoor code under cover of two or more changes that don’t introduce security holes on on their own, but do create a vulnerability when they’re combined.
And we linked to the story of a “researcher” who was so keen to remind us how easy it is to create treacherous software packages that he deliberately uploaded close to 4000 of them in a sustained burst of “helpfulness”.
As we suggested at the time, both those “experts” – the hypocrites and the overloader – seem to have adopted the selfish motto that a job worth doing is worth overdoing…
…thereby creating huge amounts of unnecessary work for other innocent volunteers in the Linux and Python communities respectively.
Colors and Faker go rogue
This time, the founder of two popular JavaScript coding modules known as colors.js and faker.js has thrown two slightly different spanners into the works.
Colors is a small and simple toolkit that helps you add coloured text in your console output, often in order to make the information more interesting to look at, and easier to read.
For example, when we made our Log4Shell – The Movie video recently, we added a dash of colour to the output of our mocked-up LDAP server to make it easier to track incoming requests, using ANSI control sequences in the terminal output to add green and red marks to denote successes and failures:
Unfortunately for colors.js users, the project’s founder, after not publishing any updates since 2019, suddenly added new code to take the release number from 1.4.0 to the somewhat unusual version identifier of 1.4.4-liberty-2.
Fed up, apparently, with never getting the financial recognition he felt he deserved from the many people that were using his work, the founder trashed his own code by adding an infinite loop like this:
/* remove this line after testing */
let am = require('../lib/custom/american');
am();
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 loop at the end of this code prints the text testing testing ... testing over and over again, after applying a function called zalgo to it.
Zalgoification
Zalgoification, if you’ve never heard of it, is a way of making regular Roman characters look weird and meaningless by littering them with accents, cedillas, umlauts and other so-called diacritical marks – a bit like naming your band Motörhead instead of Motorhead, but without the restraint of just adding a single extra symbol.
Zalgoed text is not only meaningless, but also often puts a heavy load on the underlying text rendering software that’s trying to compose it and lay it out for display.
A human calligrapher would baulk at being asked to add every possible accent to every letter in a word, knowing that it would make no sense at all.
But a computerised compositor will simply try to oblige by combining all the markings that you request, giving your band Zalgometal a stylised name something like this:
A memorial to Aaron Schwartz
Faker users experienced a different sort of update, with the project essentially wiped out and replaced with a README file asking “What really happened with Aaron Swartz?”
Schwartz, a “hacktivist” charged with federal offences relating to unauthorised access to academic papers that he thought should not be kept behind a paywall, sadly killed himself while under the stress of waiting for his trial.
and the README remembering Aaron Schwartz.
Faker was a handy toolkit for developers that made it easy to generate large quantities of realistic but made-up data for quality assurance, such as creating 100,000 names and addreses you could add to your user database during development.
Fake data is a vital aspect of avoiding a privacy disaster while you are still working with untested, incomplete code because it means you aren’t exposing genuine, sensitive data in thoughtless (and possibly illegal) ways.
The author of Faker apparently tried to commercialise the project during 2021, but without success, so it looks as though he’s now given the code its coup de grace.
Given that the code has been released for many years under the MIT licence – which basically means that anyone can use it for free, even in commercial, closed-source products, as long as they don’t claim to have created it themselves – there’s nothing to stop existing users continuing with the previous version, or indeed any version before that.
They can even make their own modifications and improvements as they wish…
…so it’s not clear what the ultimate outcome of trashing the project so spectacularly is likely to be for the author, given that he can’t retrospectively rewrite the licences of users who have already downloaded and deployed it.
Does anyone win, or do we all lose?
As one aggrieved commenter said (someone who presumably did grab the update into production without reviewing what had changed, and who suffered a temporary outage as a result), it hasn’t really ended well for anyone:
Isn’t it interesting that its the people with no reputation that seem to think reputation has no value?? To all the people in here saying “we have been taught a valuable lesson about trusting free software”; understand this…
To cause me 15 min of grief all Marak had to do was irreversibly destroy his own reputation.
Whose side are you on in a case like this? Let us know in the comments below…