Security Alert: Potential SSH Backdoor Via Liblzma

In breaking news that dropped just after our weekly security column went live, a backdoor has been discovered in the xz package, that could potentially compromise SSH logins on Linux systems. The most detailed analysis so far seems to be by [Andres Freund] on the oss-security list.

The xz release tarballs from 5.6.0 in late February and 5.6.1 on March 9th both contain malicious code. A pair of compressed files in the repository contain the majority of the malicious patch, disguised as test files. In practice, this means that looking at the repository doesn’t reveal anything amiss, but downloading the release tarballs gives you the compromised code.

This was discovered because SSH logins on a Debian sid were taking longer, with more CPU cycles than expected. And interestingly, Valgrind was throwing unexpected errors when running on the liblzma library. That last bit was first discovered on February 24th, immediately after the 5.6.0 release. The xz-utils package failed its tests on Gentoo builds.

One of the xz maintainers, [Jia Tan], weighed in on that Gentoo bug, suggesting that it was a GCC bug causing the Valgrind errors. This is the same developer that pushed the malicious archive files and minted the tainted releases. And as if to clear up any remaining doubts, the developer doubled down in a GitHub commit, working around the Valgrind errors, and linking to a completely unrelated GCC bug report claiming it to be this issue.

At this point, the only reasonable conclusion is that the person in control of the [JiaT75] GitHub account is a malicious actor and is completely untrustworthy. What’s unclear is if this is still the same developer that has been co-maintaining the project since August 2022. It’s possible that [Jia Tan] has always been a bad actor, or that account may be completely compromised.

What About SSH?

What may not be clear is the connection to SSH. And it’s a trip. Many Linux distros patch sshd to add systemd features, and libsystemd pulls the liblzma library. That means the liblzma initialization code gets run when sshd starts. In the malicious code, the library checks argv[0], which is the name of the program being executed, for /usr/bin/sshd. Additionally it seems to check for debugging tools like rr and gdb. If the checks are green, liblzma replaces a few function calls with its own code. It’s a complicated dance, but the exploit is specifically looking to replace RSA_public_decrypt.

That’s a very interesting function to clobber, as it is one of the functions used to validate SSH keys. It’s not hard to imagine how malicious code here could check for a magic signature, and bypass the normal login process. The full analysis is still being done, and expect more information in the coming days.

But the bottom line is that a machine with a patched sshd binary, that also has xz packages version 5.6.0 or 5.6.1, is vulnerable to unauthenticated SSH logins. The good news is that only a few distributions have shipped the 5.6.x series of xz packages. Fedora Rawhide/41 them, and Debian Testing and Unstable shipped these versions as well. If you’re on an affected system, look for an update right away.

It’s unclear what the path forwards is for the xz project. This is obviously an important system utility for Linux systems, and its current maintainers seem to be asleep at the wheel — or intentionally steering towards disaster. Expect one or more hard forks, and then a lot of cleanup work.

This is a developing story. For more, see the Redhat security alert, the Debian alert, and the oss-security thread on the subject.

from Blog – Hackaday https://ift.tt/b4uRXEN