[German]As of Friday, March 29, 2024, Red Hat has published a warning. The latest versions of the "xz" tools and libraries contain malicious code, a backdoor, which is apparently intended to allow unauthorized access. Affected by the backdoor (vulnerability CVE-2024-3094) are versions 5.6.0 and 5.6.1 of the libraries. Affects various Linux users and also affects Open SSH.
Advertising
Accidental discovery
A German blog reader pointed out the OpenWall post backdoor in upstream xz/liblzma leading to ssh server compromise (thanks for that). Microsoft developer Andres Freund has noticed some strange symptoms around liblzma (part of the xz package) under Debian sid installations in the last weeks. His logins with ssh required a lot of CPU power, there were valgrind errors etc.).
He then looked into the matter and found a reason for this: The upstream xz repository (also used by sssh) and the xz tarballs were backdoored. At first he suspected that the Debian package had been compromised, but discovered that the backdoor is contained in the upstream package. The discoverer describes some details in his post.
Since then, the Linux world has been in an uproar, as it affects various products (tarballs, ssh) in various Linux distributions. Someone on X has already sent me the information that GitHub has suspended the XZ repository after the disclosure of the backdoor – but notes that the GitHub platform has been "nothing but garbage" since the takeover by Microsoft.
German blog reader Norddeutsch has summarized it in the discussion section of the blog. "XZ backdoor makes further waves. For Backdoor, manipulation of Google's oss-fuzzing via fake request was attempted to prevent detection. HackerNews discusses, further reviews exist. A good analysis of the issue can be found on GitHub, the manipulation via oss-fuzz can be found on Github/Google. There is a thread about it on HackerNews.
Warning from Red Hat
Friday, March 29 2024, Red Hat issued a warning that the latest versions of the "xz" tools and libraries contain malicious code, a backdoor that appears to be designed to allow unauthorized access. It states:
Advertising
Malicious code has been discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a pre-built object file from a disguised test file in the source code, which is then used to modify certain functions in the liblzma code. The result is a modified liblzma library that can be used by any software that is linked against this library and that intercepts and modifies the data interaction with this library.
Affected by the backdoor (CVE-2024-3094, CVSS ccore 10.0) are versions 5.6.0 and 5.6.1 of the libraries. Red Hat states that current investigations show that the packages are only present in Fedora 41 and Fedora Rawhide within the Red Hat Community ecosystem. No versions of Red Hat Enterprise Linux (RHEL) are affected, Redhad states. The Register writes here that certain Fedora 40 systems may also have received the update.
In any case, the use of Fedora Rawhide instances should be discontinued immediately. Other Linux distributions are also likely to be affected by these xz tools and libraries.
It seems, however, that in many cases it went well again – presumably only "unstable" distributions were affected. The Internet Storm Center writes in this tweet:
A quick note about xz-utils backdoor:
1 – luckily, this was caught early.
2 – most run xz-utils 5.2/5.4. 5.6 is bad.
3 – quick check: `xz -V`
4 – Thanks to people who paid attention
So the backdoor was discovered before it was in widespread use. Fedora Rawhide / Fedora Linux 40 / openSUSE Tumbleweed may be affected. You can test it with the command mentioned above under 3, which displays the version.
The discussions in this thread shed some more light on how the backdoor could get into the code. The colleagues from Bleeping Computer have also compiled some information on this here.
FYI: Alpine Linux had the XZ version in question in the most recent version, but there it wasn't hooked into SSH for systemd support(*) which reduced the footprint by a lot.
In general, this is one on the "open source works!" side of discoveries, opposed to the things like the Solarwinds attacks.
Largely to the effort of the user who investigated it and prepared such a good report that it didn't get discussed away.
Lessons to maybe learn:
– The parallels with the debian RNG disaster and with heartbleed (distros mingling in security related upstream software, keeping a sharp eye on critical components)
– How important it is to keep your eyes open for the little things like a slower login. They might just be anything, but it'll always help to fix them and not just nod it off.
– Criticality of central libraries (compression, security, regex, libc) needs to be considered differently from others
– projects should raise alarms internally (and have channels for it) if someone sends patches out of the scope of normal work, tries to "streamline" their security policies or modifies build scripts along with some other feature (code != infra)
– there'll never be a SWBOM in the stages where these attacks are effective
– Each new OS release that you test is a new integration IN FULL and should be handled as a new env until you go into deployment phases
– there need to be clear boundaries between critical services and their helper libraries(*)
– we don't know how to deal with the contradiction that outdated libaries and openssl/openssh in FIPS mode repeatedly proved less fatal than the modern, more secure by design components we strive to use. It seems it could make sense to treat the core system differently from the application layer (a bit like FreeBSD base vs. ports had it, which there we consider one of the advantages but it is never just an easy decision. i.e. do i want PFS support (safe against state actors until it leaked creds) or FIPS (outdated version with lots of minor flaws)?
(*) I expressed arguments pro systemd when asked by debian maintainer in 2014. My reasoning was that a common standard, even if questionable, was a good thing as it establishes a shared platform for improvement.
I am very, very sorry.