CachyOS Making Use Of Plymouth For Better Boot Experience, Mitigates For XZ Fiasco

[phoronix]

Phoronix: CachyOS Making Use Of Plymouth For Better Boot Experience, Mitigates For XZ Fiasco

CachyOS as a reminder is the Arch Linux based distribution focused on providing a very performant out-of-the-box experience and supports x86-64-v3 and x86-64-v4 packages along with other default changes compared to upstream Arch Linux. The April 2024 ISO release of CachyOS is now available for those wanting to enjoy a fresh spin of this rolling-release, performance-tuned platform...

https://www.phoronix.com/news/CachyOS-April-2024-Released

[ptr1337]

Thanks for posting Michael .

This was a quite unintended release, but due the xz CVE we decided to bring it.
Anyways, CachyOS and Arch doesnt seem to be affected at all, but better safe then sorry.

[patrakov]

The question is not whether Arch and CachyOS were affected at all, but whether the purported "fix" does anything at all. And I know for sure that it doesn't: the disassembly of the liblzma.so.5.6.1 library before and after the fix is identical, the only difference is in ELF headers. IMPORTANT EDIT: The previous statement about the identical disassembly applies to Arch Linux only. I have not checked CachyOS, and I know for sure that the backdoor does exist in Debian.

Doing something "just in case" and not issuing official statements debunking the provably-false information in the security advisory given this level of evidence is only fueling conspiracy theories. Due to this, in my past job, auditors (who were previously OK with Arch Linux) could scream "please wipe the disk and install Windows just in case".

[Jaxad0127]

The question is not whether Arch and CachyOS were affected at all, but whether the purported "fix" does anything at all. And I know for sure that it doesn't: the disassembly of the liblzma.so.5.6.1 library before and after the fix is identical, the only difference is in ELF headers. IMPORTANT EDIT: The previous statement about the identical disassembly applies to Arch Linux only. I have not checked CachyOS, and I know for sure that the backdoor does exist in Debian.

Did you check that they actually have the exploit code? There are claims out that the build scripts check for rpm or deb environments before creating the exploit.

[ptr1337]

The question is not whether Arch and CachyOS were affected at all, but whether the purported "fix" does anything at all. And I know for sure that it doesn't: the disassembly of the liblzma.so.5.6.1 library before and after the fix is identical, the only difference is in ELF headers. IMPORTANT EDIT: The previous statement about the identical disassembly applies to Arch Linux only. I have not checked CachyOS, and I know for sure that the backdoor does exist in Debian.

Doing something "just in case" and not issuing official statements debunking the provably-false information in the security advisory given this level of evidence is only fueling conspiracy theories. Due to this, in my past job, auditors (who were previously OK with Arch Linux) could scream "please wipe the disk and install Windows just in case".

We followed here archlinux and their suggestions.
With the current known analysis related to the sshd linking, CachyOS nor Archlinux were not directly affected.
We have rebuild xz directly from source, without the malicious test the same for libarchive.

We dont provide a customized ssh, which means it is currently not linked against liblzma.

[mb_q]

Doing something "just in case" and not issuing official statements debunking the provably-false information in the security advisory given this level of evidence is only fueling conspiracy theories. Due to this, in my past job, auditors (who were previously OK with Arch Linux) could scream "please wipe the disk and install Windows just in case".

In Arch (contrary to Fedora/Debian) sshd is not loading liblzma, so the discovered xz backdoor code is not executed, and the system is safe. They have sent a patch "just in case" there are other surprises in the xz. Still, the whole operation seem to be designed to be stealth and attack a very specific target, hence they are unlikely.

[Quackdoc]

I've been trying the cachyOS kernels on arch and I have to say, I think somethings wrong, particularly the linux-cachyos-sched-ext and it's been really stuttery. it was fine when I compiled it against arch's main kernel with the patches applied so I think something is funky with the kernel, plan on testing their eevdf kernels soon but has anyone else experience similar issues? Maybe it's just one of those things were I need to test it on cachy itself?

[pWe00Iri3e7Z9lHOX2Qx]

In Arch (contrary to Fedora/Debian) sshd is not loading liblzma, so the discovered xz backdoor code is not executed, and the system is safe. They have sent a patch "just in case" there are other surprises in the xz. Still, the whole operation seem to be designed to be stealth and attack a very specific target, hence they are unlikely.

I wouldn't say "very specific" in this case. The fact that they only cared about RPM and DEB build targets basically tells you they cared about all the enterprise distros (RHEL / SUSE / Ubuntu / Debian). It was a combination of timing / luck / one curious mind that avoided a total farking disaster several months down the line. One dude (employed by Microsoft) doing some micro-benchmarking.

I didn't even notice it during logging in with ssh or such. I was doing some micro-benchmarking at the time and was looking to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd. Which showed lots of cpu time in code with perf unable to attribute it to a symbol, with the dso showing as liblzma. Got suspicious. Then recalled that I had seen an odd valgrind complaint in my automated testing of postgres, a few weeks earlier, after some package updates were installed. Really required a lot of coincidences.

Whoever these shitheads were, they even had Google's OSS-Fuzz project disabled ahead of time for XZ to try and make sure the fuzzer wouldn't pick up their changes.

[pWe00Iri3e7Z9lHOX2Qx]

Thanks for posting Michael .

This was a quite unintended release, but due the xz CVE we decided to bring it.
Anyways, CachyOS and Arch doesnt seem to be affected at all, but better safe then sorry.

Do you know if there are any plans to support encrypted root ZFS installs? I know you can already do unencrypted, but an easier path to an encrypted ZFS on root install would be great, especially with the option to omit a bootloader installation so folks could grab ZFSBootMenu instead.

[ptr1337]

Do you know if there are any plans to support encrypted root ZFS installs? I know you can already do unencrypted, but an easier path to an encrypted ZFS on root install would be great, especially with the option to omit a bootloader installation so folks could grab ZFSBootMenu instead.

We already support encrypted ZFS installs via LUKS since around 9 months.
We found an issue together with plymouth, when used with zfs encryption and will provide in the next hour a fix (this gets ondemand applied at the users online installation).

Currently via Calamares there is only a direct on root install possible, like with own disk/partition. We are planning to provide zfsbootmenu support in the CLI Installer.