A developer, curious about a slight performance lag on his computer, accidentally discovered the XZ attack—a backdoor that reminds us some of our biggest open-source security threats are from decades of unlearned lessons.
The hero of our story is Andres Freund, a Microsoft developer who in March 2024 noticed his Linux system’s ssh service was a bit sluggish. Digging deeper, he found a malicious backdoor intentionally planted in liblzma, a common data compression library. The hidden code was designed to let an attacker execute any command on a target machine.
According to Russ Cox, who led Google’s Go programming language team for over a decade, this “brand new” attack is anything but. He points to a 1974 US Air Force report (PDF) on the Honeywell Multics system, a document from the dawn of modern computing. That review warned of a theoretical “trap door” hidden in a system call that, with the right secret input, could unlock the entire kernel. The playbook for the XZ attack discovered by Freund was written fifty years ago.
The first open-source security lesson: Know your enemy
To fight this threat, we have to understand it. Cox explains that an open-source software supply-chain attack is when someone deliberately slips malicious code into trusted software before it gets to you. It’s necessary to distinguish this from a vulnerability, which is an honest mistake or a bug that creates a security hole.
The devastating Log4j flaw that affected millions of programs was an accidental bug, making it a vulnerability, not a targeted attack. The same goes for the bug in an open-source image decoder that allowed attackers to take over iPhones with a single message; it was a serious, but accidental, flaw.
These supply-chain attacks are also specifically about open-source code. When hackers altered Juniper Networks’ private VPN source code, it was a supply-chain breach, but not an open-source one. The goal is always the same: compromise the building blocks that many developers trust.
XZ attack offers a masterclass in stealing a project
The XZ attack was a security masterclass of using human manipulation to steal an open-source project. The story begins with Lasse Collin, the volunteer creator of the XZ project back in 2005. In late 2021, an attacker – hiding behind the name “Jia Tan” – started submitting helpful patches.
Over two years, this malicious actor and a cast of fake online personas created a pressure cooker of criticism. They publicly complained that the project was moving too slowly and shamed Collin for not having enough time, writing things like, “The current maintainer lost interest or doesn’t care to maintain anymore.”
Eventually, the pressure worked. Collin handed over more and more control to the attacker, who patiently built trust before finally springing the trap in early 2024.
This entire takeover was possible because of the fragile state of open-source funding. It has similarities to the 2014 “Heartbleed” crisis, where the OpenSSL library – which secured billions in commerce – was run by a handful of volunteers on just $2,000 a year in donations.
For a nation-state, the cost of paying a developer to infiltrate a project is pocket change compared to the prize.
Improving defences to prevent threats like the XZ attack
So, how do we fight back? There’s no magic fix, but Cox argues we can and must build stronger walls to improve open-source security.
The first step is proving our software is what it claims to be through authentication. Cryptographic signatures are the best tool we have. Systems like the Go checksum database create a permanent, unchangeable record of what a specific version of a software package should look like. This stops attackers from quietly modifying code in transit and forces them into the open.
Next, we need reproducible builds. The XZ attacker hid their malicious code in the final compiled files, not the public source code. If builds are reproducible, anyone can take the same source code and confirm it produces the exact same result, leaving nowhere for malware to hide.
We also have to get better at finding and fixing flaws fast. That means constant scanning for known vulnerabilities and having the ability to deploy patches in hours, not months. After the Log4j incident, regulators even warned companies they could face legal action for not updating their systems promptly.
Finally, we need to prevent vulnerabilities from happening in the first place. This means being ruthless about adding new dependencies. The XZ attack only worked on systems like Debian because a patch had added the dependency that opened the door for the attack. Moving to memory-safe languages like Go or Rust can also wipe out entire categories of common security bugs that plague older languages like C and C++.
Can we really trust anything when it comes to open-source security?
In his famous 1983 lecture, computing pioneer Ken Thompson said something that should haunt every developer today: “You can’t trust code that you did not totally create yourself”. Yet our entire digital world is built on doing just that, every single day, especially with increasing use of AI coding assistants.
The discovery of the XZ attack feels like we dodged a bullet, but it was found by pure chance. As Cox wonders, “What are the chances we would accidentally discover the very first major attack… in just a few weeks? Perhaps we were extremely lucky, or perhaps we have missed others.”
The scary part is that attackers don’t need to be geniuses. They just need to find one of the numerous overworked volunteers and ask if they need a hand.
See also: Escalating npm supply chain malware attack drains crypto wallets
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events, click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
