 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
You may never have heard of the xz data compression code, but it’s vital to numerous programs, and we now know someone has planted malicious code in it.
When Red Hat first broke the news that the latest version of the xz data compression libraries contained a booby trap, People were concerned but not too worried. After all, they reasoned, it appeared many at first thought it was just another security hole. While others thought that if it only affected the Fedora Linux 40 beta, how bad could it possibly be?
The answer: Very, very bad indeed.
You see, while no one in their right mind would run a Fedora beta in production, the problem isn’t with Fedora. It’s with the new xz libraries: xz-libs-5.6.0-1.fc40.x86_64.rpm and xz-libs-5.6.0-2.fc40.x86_64.rpm.
The libraries contain malicious code designed to enable attackers to take over systems, with unauthorized access. This backdoor malware was written into the upstream xz repository and then placed in its tarballs.
In a word, that’s bad, with capital letters.
Red Hat gave this malicious code in its CVE-2024-3094 report the highest possible Common Vulnerability Scoring System (CVSS) rating of 10. Or, as I like to call that level of bug, it’s “rip the power cord out of the wall now and save yourself any additional pain” time.
Andres Freund, a Microsoft principal software engineer, analyzed the xz malware. Freund found the attacker had injected an obfuscated script that activated the backdoor. In some cases, its main attack wouldn’t work, and the only result was to massively slow down SSH logins.
Indeed, in the case of the popular SSH program OpenSSH, you don’t even need to start it as a server for the slowdown effect to hit your system. Since SSH is essential for Linux development and administration, that’s more than bad enough.
What really makes this a major PITA problem is that these libraries aren’t just in Fedora. Oh my, no. Xz is a core Linux utility. You’ll find these libraries everywhere.
The most troubling thing about this incident is that it appears a trusted xz maintainer, Jia Tan, was the hacker.
Freund said, “Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system. Unfortunately, the latter looks like the less likely explanation, given that they communicated on various lists about the ‘fixes’ mentioned above.”
While malicious code has been injected into trusted open source code by maintainers before, it’s a truly rare occurrence. To the best of my knowledge, this has never happened to an important Linux utility before.
Oh yeah, there may be more security snakes hiding in the grass. Freund admits, ” I am not a security researcher, nor a reverse engineer. There’s lots of stuff I have not analyzed, and most of what I observed is purely from observation rather than exhaustively analyzing the backdoor code.”
The good news — there is some — is that xz 5.6.0 and 5.6.1 have not yet widely been included in Linux distributions. Where it has been incorporated, the code has mostly been in pre-release versions. The bad news is, besides Fedora, it’s already in early versions of Debian, openSUSE, Ubuntu, etc. You name it, and it’s a cutting-edge distribution or a beta, chances are the bad code is hiding inside.
So what can you do about it? Well, the default suggestion is to revert away from xz 5.6.0/5.6.1. But, warns Debian developer Joey Hess, that may not be enough. Hess fears Tan may have hidden other backdoors in xz. Hess suggests you revert all the way back to xz 5.3.1.
If, of course, you can find that code. GitHub has disabled the xz repository. This really is a first-class rip-roaring security mess.
People have long been concerned with xz’s code quality and, indeed, some of the project’s basic premises. With this foul-up, I think it’s time to seriously consider pulling xz and replacing it from the source code up.
Most users won’t be affected by this malware, but if it had gone undetected for two or three more months, everyone using Linux would have faced its biggest security disaster ever.
