The recent XZ backdoor issue has caused quite a turmoil through out the software community. However, I don’t think this will change anything. In this post explore how the XZ Utils backdoor happened, investigate similar incidents from the past, and argue why this doesn’t matter.
Table of Contents
XZ Utils Backdoor
Background
XZ Utils is a set of free software command-line lossless data compressors. A developer named Jia Tan gained the trust of its maintainer over the course of three years. This eventually led to Jia Tan’s appointment as co-maintainer of XZ Utils. Jia Tan was able to sign off on version 5.6.0, which introduced a backdoor.
The whole situation was intricately planned, as there was even a period when the maintainer was pressured to hand over control of the project through apparent sock puppetry. As a result, two versions of XZ—5.6.0 and 5.6.1—were compromised, with a backdoor hidden in the program.
How It Got Caught
Microsoft employee and PostgreSQL developer Andres Freund discovered a backdoor while investigating a performance regression in Debian Sid. Freund observed that SSH connections were causing an unusually high CPU load and generating errors in Valgrind, a memory debugging tool. He reported his findings to the Openwall Project’s open source security mailing list, which alerted various software vendors to the issue.
Ramifications
The backdoor was quickly declared CVE-2024-3094 and received highest severity score of 10. Linux software vendors, including Red Hat, SUSE, and Debian, have reverted the affected packages to older versions. GitHub disabled the mirrors for the xz repository before subsequently restoring them.
Similar Incidents
XZ Utils backdoor issue quickly reminded me of two previous incidents. These incidents may be somewhat different in its nature, however, in the grand scheme of things, similarly pertain to possibility of introduction of intentional vulnerability in open source code.
University of Minnesota Banned For Intentionally Contributing Bugs
Greg Kroah-Hartman, a Linux Foundation Fellow responsible for stable Linux kernel releases, has banned the University of Minnesota from contributing to the kernel. This decision followed the revelation that two students had intentionally added faulty code as part of a study titled “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits.”
These “hypocrite commits” aimed to introduce hidden vulnerabilities under the guise of beneficial contributions, specifically targeting the Linux kernel due to its widespread use. In a message to the Linux kernel mailing list, Kroah-Hartman expressed his displeasure with the experiments on the community, announced the ban on all future contributions from the university, and his intention to remove their previous submissions, citing bad faith and potential disruption.
This action affects all five schools within the University of Minnesota system. Further updates will be provided pending responses from the university and Kroah-Hartman.
source: https://www.tomshardware.com/news/linux-fellow-bans-university-contributing-kernel
NSA Asked Linus for Backdoor in Linux
The NSA allegedly approached Linus Torvalds, the creator of Linux, to create backdoors in GNU/Linux, allowing them access. This claim comes from Linus’ father, Nils Torvalds, a Member of the European Parliament, who shared this information during a committee inquiry on mass surveillance of EU citizens.
While Linus publicly denied being approached by the NSA, Nils suggested that Linus was signaling the opposite by nodding while denying the claims. This revelation follows accusations that major tech companies like Google, Yahoo!, Facebook, and Microsoft have cooperated with the NSA to provide backdoor access. Nils emphasized the safeguards inherent in open-source development, which would likely prevent any such backdoors from remaining undetected and unaddressed.
XZ Backdoor Won’t Change Anything
While XZ backdoor notable because of the intricacy of plan by the attacker, severity of the vulnerability, and implication of damage caused if the vulnerability wasn’t discovery accidentally. However, I don’t think this kind of issues will ever go away.
This Cannot Be Stopped
Much of the world’s software now heavily relies on open source projects, and this trend is likely to continue. Without open source projects, creating any new software would be prohibitively expensive. You would literally have to implement everything yourself.
Meanwhile, open source will continue to be poorly funded and understaffed. As sad as it is to acknowledge, people like things free as in beer, including both contributions of funds and code.
Thus, people will continue to depend on open source while it remains underfunded and understaffed. Will this ever change? I certainly hope so, but I’m also a bit doubtful. While these two things remain the same, attempts just like XZ Utils backdoor will continue.
Managing Dependency Was Always Important
Is it all doom and gloom for us developers? In situations like these, the best course of action is to closely monitor community updates and adjust your dependencies accordingly, steering clear of problematic versions such as XZ Utils 5.6.0 and 5.6.1. But wait isn’t that what we have always done?
Indeed, the XZ Utils backdoor is a serious issue, and similar incidents are likely to recur. There appears to be no end in sight to these types of security challenges. However, managing dependencies to avoid bugs and vulnerabilities has always been a fundamental responsibility for developers. Thus, for better or worse, the discovery of the XZ backdoor doesn’t fundamentally alter our approach; we must continue to vigilantly follow community developments and meticulously manage our version control.
On a side note, I employ a preventive tactic that serves as a rule of thumb: I generally skip at least the first patch version of a minor upgrade and two patch versions of a major upgrade. This strategy provides time for the identification and resolution of any issues that may emerge with new releases, thus minimizing the risk of integrating defective updates into my projects. While this method isn’t foolproof, it does provide a valuable layer of protection against the integration of newly introduced vulnerabilities.