Backdoored liblzma (CVSS 10.0) might be present in qubes-template-archlinux 4.2.0-202403061411

[no-usernames-left]

Hello,

liblzma has been backdoored upstream (CVE-2024-3094, CVSS 10.0):
https://www.openwall.com/lists/oss-security/2024/03/29/4

It would appear as though this has affected users of Qubes OS:
https://forum.qubes-os.org/t/qubes-users-kernel-paman-8748-segfault-at-58326dd13cf4-ip-00005837ecf00a71-sp-00007fff91f540b0-error-4-in-paman-5837ecefd000-1b000-likely-on-cpu-1-core-0-socket-0/25029

I am on mobile right now and cannot develop this issue further, but I wanted to make some noise about it to get people's attention.

[renehoj]

dom0 doesn't have liblzma installed, and debian 12 has v5.4.1-0.2

I think both should be safe, not sure about the fedora templates.

[marmarek]

Dom0 has xz-5.4.1, which doesn't include that backdoor. Neither Fedora 39 nor Debian 12 are affected.

The Archlinux template in the "templates-community-testing" repository might be affected, rebuild is in progress. But community templates are not included in the standard security process, so there won't be Qubes Security Bulletin about it.

[no-usernames-left]

Apparently Kali was also hit as of 26 March.

[no-usernames-left]

Fedora 40 and 41 were apparently targeted:
https://news.ycombinator.com/item?id=39866275

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.

He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.

[no-usernames-left]

https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094

[no-usernames-left]

We should look at libarchive too; from the same person who backdoored liblzma:
libarchive/libarchive#1609

tukaani-project/xz#94

[no-usernames-left]

Dom0 has xz-5.4.1, which doesn't include that backdoor.

@marmarek xz-5.4.1 was released by the very same person who inserted the backdoor into 5.6.0/5.6.1:
https://github.com/tukaani-project/xz/tree/v5.4.1

Are you sure it's trustworthy, especially given it's in dom0 and thus in the Qubes TCB? I sure wouldn't put my money on it.

[no-usernames-left]

A very good writeup which is being updated in real time as more layers of the onion are being peeled:
https://boehs.org/node/everything-i-know-about-the-xz-backdoor

[DemiMarie]

Dom0 has xz-5.4.1, which doesn't include that backdoor. Neither Fedora 39 nor Debian 12 are affected.

The Archlinux template in the "templates-community-testing" repository might be affected, rebuild is in progress. But community templates are not included in the standard security process, so there won't be Qubes Security Bulletin about it.

FWIW my understanding is that the Arch template had the backdoored version, but the backdoor disables itself unless it detects an RPM or deb package being built, so the backdoor wasn’t included in the final binary. Also, the backdoor appears to only target sshd, rather than e.g. infecting all files on the system or all files processed by xz.

[DemiMarie]

Hello,

liblzma has been backdoored upstream (CVE-2024-3094, CVSS 10.0): https://www.openwall.com/lists/oss-security/2024/03/29/4

It would appear as though this has affected users of Qubes OS: https://forum.qubes-os.org/t/qubes-users-kernel-paman-8748-segfault-at-58326dd13cf4-ip-00005837ecf00a71-sp-00007fff91f540b0-error-4-in-paman-5837ecefd000-1b000-likely-on-cpu-1-core-0-socket-0/25029

libalpm (which Pacman wraps) is known to have a bug (now fixed in upstream git) that causes a NULL pointer dereference under certain conditions. Qubes OS templates with the Qubes repos enabled are affected. I believe that this is the actual cause of the crash.

[patrakov]

Just in case, the official recommendation to upgrade to xz 5.6.1-2 looks suspicious: the liblzma.so.5.6.1 files from both the supposedly-trojaned 5.6.1-1 and "fixed" 5.6.1-2 versions are not identical, but have 100% identical disassembly by objdump -d. Therefore, I would not recommend blindly following the official recommendation to upgrade to 5.6.1-2 and claiming that the vulnerability is thereby fixed, as that's a no-op by that "identical disassembly" argument.

[DemiMarie]

@patrakov On Arch, the backdoor did not include itself in the build, so this is expected.

[marmarek]

@patrakov On Arch, the backdoor did not include itself in the build, so this is expected.

Lowering priority. But it's still worth to rebuilt with reverted version, just in case.

[kpcyrd]

libalpm (which Pacman wraps) is known to have a bug (now fixed in upstream git) that causes a NULL pointer dereference under certain conditions. Qubes OS templates with the Qubes repos enabled are affected. I believe that this is the actual cause of the crash.

I've requested a backport: https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/24

[marmarek]

The Arch template is rebuilt (although it turned out to not be necessary), other supported templates are not affected (we don't have Fedora 40 nor Debian unstable templates yet).