Researchers have found a malicious backdoor in a compression tool that made its way into widely used Linux distributions, including those from Red Hat and Debian.
The compression utility, known as xz Utils, introduced the malicious code in versions 5.6.0 and 5.6.1, according to Andres Freund, the developer who discovered it. There are no known reports of those versions being incorporated into any production releases for major Linux distributions, but both Red Hat and Debian reported that recently published beta releases used at least one of the backdoored versions—specifically, in Fedora Rawhide and Debian testing, unstable and experimental distributions. A stable release of Arch Linux is also affected. That distribution, however, isn't used in production systems.
Because the backdoor was discovered before the malicious versions of xz Utils were added to production versions of Linux, “it's not really affecting anyone in the real world,” Will Dormann, a senior vulnerability analyst at security firm Analygence, said in an online interview. “BUT that's only because it was discovered early due to bad actor sloppiness. Had it not been discovered, it would have been catastrophic to the world.”
Several people, including two Ars readers, reported that the multiple apps included in the HomeBrew package manager for macOS rely on the backdoored 5.6.1 version of xz Utils. HomeBrew has now rolled back the utility to version 5.4.6. Maintainers have more details available here.
Targeting sshd
The first signs of the backdoor were introduced in a February 23 update that added obfuscated code, officials from Red Hat said in an email. An update the following day included a malicious install script that injected itself into functions used by sshd, the binary file that makes SSH work. The malicious code has resided only in the archived releases—known as tarballs—which are released upstream. So-called GIT code available in repositories aren’t affected, although they do contain second-stage artifacts allowing the injection during the build time. In the event the obfuscated code introduced on February 23 is present, the artifacts in the GIT version allow the backdoor to operate.
https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/patches/systemd-readiness.patch
… and to support the socketd activation mode where sshd does not need elevated permissions so it can listen to a privileged port:
https://salsa.debian.org/ssh-team/o...ebian/patches/systemd-socket-activation.patch
Both of those are reasonable features, one of which is a security improvement, and all your trolling is doing is distracting from a carefully premeditated attack which could have been carried out against almost anything. The reason they picked xz is no doubt because it's popular and widely used. If that didn't exist, they could have picked one of the 40-odd other packages it depends on or found something else.
Yeah, my point wasn't that closed source is better but simply that open source projects are exposed because there are many projects which are widely used, accept contributions from anyone on the internet, but have only a handful of maintainers. Microsoft doesn't accept pull requests for Windows on GitHub but if they did, they'd also have the budget to hire people whose full-time job would be to review things.
As a long-time open source contributor, this trend has been fairly sad because so much of the internet used to run on a community trust model that frankly isn't sustainable. Most of the ways we could combat this are going to directly impact one of the things I used to like the most: people are going to rely more on reputation, which means someone with a contribution from, say, @google.com is going to get their stuff merged faster than someone at @Gmail.com, which I don't like even if I completely understand why that will happen.
But who knows how many other Linux packages are backdoored by other malicious upstream software developers. If it can be done to one project, it can be done to others just the same.
P.S. Address sanitizer really does need to be disabled when working with ifuncs, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110442. Maybe valgrind has a similar bug? (Not sure; that's pure speculation.) That could explain why the other developers were not more suspicious of the malicious commits that hid the problems.