Skip to main content




The XZ attack has taken the world of cybersecurity by storm. This video provides a concise overview. (If you prefer text, there is a link to a text-based FAQ below.)

It begins with a clever "social engineering" attack, where two people play "good cop bad cop" to guilt-trip the maintainer of XZ. First I should probably mention that XZ Utils is a compression system used by Linux, in lots of places including package managers, build (code compilation) systems, and ssh, the "secure shell" system that enables people to log in to remote servers and run commands. (I myself use ssh dozens of times every day -- if you don't work with servers you wouldn't know, but this is how servers are managed all over the internet.) Getting back to the "social engineering" attack, the attackers successfully demoralized the project maintainer, who was an open source developer working in his spare time and not paid. He eventually gave up and made the "good cop" co-maintainer of the project.

The attack itself is pretty interesting, too. The attacker did not touch ssh, or at least not the code for ssh itself. He changed test code. And not in an obvious way -- he changed a "binary blob" that is opaque to people examining changes to the code to decide whether to accept the changes on their systems or not. The binary blog would get decompressed at build time, and it turned out inside it was a bash script (bash is another one of those Linux shells), and the bash script would get executed. The bash script would modify the ssh system in such a way that a certain public key would be replaced by a different one. The purpose of the original public key was to make sure only trusted people with the corresponding private key could update a running ssh system. With the attacker's key in place, the attacker can now change running ssh systems. Not only that, but because an ssh installation on a server runs with root privileges, because it has to because it has to be able to authenticate any user and then launch a command-line shell for that user with that user's privileges, the attacker becomes able to log in as root on any Linux server infected with the attack -- which could have eventually become more or less all of them had the attack not been discovered.

To me, this attack is interesting on so many levels:

1) It comes through the "supply chain" -- attacking open source at the point where contributors (often unpaid) submit their contributions.

2) It involves a "social engineering" attack on the supply chain, something it had never occurred to me was even possible before.

3) There was a long delay between the social engineering attack and the technical attack -- about 2 years. The attackers spent 2 years building trust to exploit later.

4) It attacks one piece of software (ssh) by attacking a completely different and apparently unrelated piece of software (XZ Utils).

5) It attacks the software not by attacking the code to the software directly, but to its test code.

6) It carries out the attack by running malicious code at build time instead of runtime. (The build of XZ Utils is part of the build of ssh.)

7) It attacks a cryptosystem by replacing a legitimate key with the attacker's key and getting the attacker's key "officially" distributed.

8) Had it been successful, the implications would have been huge -- it would have given the attacker access to practically every Linux server everywhere. (Well, every Linux server, pretty much, uses ssh but the attack initially targeted RedHat & Debian, so maybe it wouldn't have spread to everywhere.)

9) The attack was discovered accidentally, because it modified its target's performance, not any other aspect of its behavior.

I hadn't mentioned that last one yet, but yeah, the attack was discovered by a person who was doing performance benchmarks on a completely unrelated project (to do with the Postgres database), which just happened to include automated ssh logins as part of the testing system, and the ssh logins suddenly slowed down for no apparent reason. In trying to figure out what had gone wrong, he discovered the attack.

This has huge implications for the future for open source software and trust in all the projects and maintainers and regular software updates that are done on a daily basis all over the world. Some are predicting wholesale abandonment of the package distribution systems used currently throughout the Linux world. At the very least, everyone contributing to projects that become standard parts of Linux distributions is going to come under much greater scrutiny.

And in case you're wondering, no, nobody knows who the attackers were, at least as far as I know. And no, no one knows how many other attacks might exist "out there" in the Linux software supply chain.

#solidstatelife #cybersecurity


Neil E. Hodges reshared this.

in reply to gunnar

The lessons to be taken from this is that developers and maintainers of CRITICAL systems which most other things depend on need to be PAID PROPERLY by the fucking corporate charging parasites like Redhat and Oracle..

Looking at this as a dev of sorts I see a state actor behind this.. Your normal hacking kid won't spend years and leave such a blatant trail of their deeds and activities.. they haven't got the paitence.

in reply to gunnar

@juliadream@iviv.hu That's what you're saying have been often mentioned ten years ago after heartbleed... Everyone agreed...
in reply to gunnar

I know.. I was one of the people saying it. I was proud one day when Richard Stallman quoted me back during the Creative Labs fiasco. Some of us move in interesting circles... oh yeah and FUCK IBM !!!
in reply to gunnar

I would like to see maintainers of critical systems paid properly also. Maybe the maintainer of ssh will be paid well after this. I worry, though, that people don't realize what systems are "critical systems" until after they get hacked...
in reply to gunnar

That also bothers me. As a long time unix/linux user I always watch the dependencies and see just how many small things are actually vital critical things which if broken would take down everything else... and as always I watch gstreamer and gcc versions.. they just love breaking those dependencies. Dammit I remember trying to get audio working on Debian back in the late 1990's!! Life is so much better these days.. but sometimes they still like throwing us a curveball..

Daily driver Mint (still on 20.3 actually.. it works just fine.. had to roll it back a week or so ago because the kernel update broke my nvidia 470 driver.. Mission critical machines don't need constant updates..) and for hotter things that aren't important then it's currently Manjaro by choice..