Bug 14383

Summary:	[2023.1] xz 5.6.1 from upstream has a back-door - CVE-2024-3094
Product:	[ROSA-based products] ROSA Fresh	Reporter:	Giovanni Mariani <mc2374>
Component:	Packages from Main	Assignee:	ROSA Linux Bugs <bugs>
Status:	CONFIRMED ---	QA Contact:	ROSA Linux Bugs <bugs>
Severity:	critical
Priority:	High	CC:	m.novosyolov
Version:	All
Target Milestone:	---
Hardware:	All
OS:	Linux
URL:	https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/
Whiteboard:
Platform:	2023.1	ROSA Vulnerability identifier:	CVE-2024-3094
RPM Package:		ISO-related:
Bad POT generating:		Upstream:

Description Giovanni Mariani 2024-03-30 15:58:22 MSK

Yesterday emerged that upstream xz repository and the xz tarballs it provides have been back-doored.
See the original report:
https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/
And a couple of summaries:
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
https://boehs.org/node/everything-i-know-about-the-xz-backdoor

A portion of the backdoor (ie the m4 script - build-to-host.m4 - that installs it at build time) is *solely in the distributed tarballs*, ie *not* in the upstream source of build-to-host. It is present in the tarballs released upstream, except for the "source code" links.
The m4 script is obfuscated and is executed at the end of configure. This
script use data from "test" .xz files in the repository: the tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma files; they contain the bulk of the exploit, to be inserted in the liblzma5 library at build time.

It also looks like the upstream maintainer is directly involved in introducing the malicious code in the upstream repository... so any release after his involvement (around 2021) is potentially compromised.

As an emergency workaround I did a rebuild of xz 5.6.1 using the sources automatically generated by GitHub instead of the released ones. They does not have the m4 script, but still have the two "fake" test files listed above (simply removing them makes the tests to fail even if they seem to be unused).
This should produce binaries without the back-door.
But it is not certain that there are no other mine fields in the actual sources.

Now we should decide ASAP what to do...
The absence of the evil build-to-host.m4 in our actual source could be enough to avoid the back-door presence, but this is not 100% sure and perhaps there is other malicious stuff lurking...
Debian has packaged the 5.4.5 sources with the 5.6.1 name, but is it unknown if this release is really safe, given its release date. Surely it does not have the above fake test files, but there is no guarantee about the absence of other evil code presence.
In 2021.1 we have the 5.2.9 release: it was released before the arrival of the malicious maintainer so it could considered safe.

What will we do? Keep the actual source and hope for the best, while waiting for a more thorough audit of the code? Downgrade xz to the first "safe" release? (but we will have to add all the security fixes that happened after that and to resolve the problem of symbols present in the later releases and missing in the older one...)

Comment 1 Mikhail Novosyolov 2024-03-30 17:24:19 MSK

I also thought about rolling back to the last 5.4.x version released by the previous upstream maintainer, but cannot find many advantages of doing so after you switched to a gz tarball without that malicious script instead of xz.
It is not clear what we will do further after rolling back. Of course, we will rebuild all cosumers of the library to solve problems with symbols.
Maybe also remove malicious test files in %prep to make sure that they are not used anyhow during the build?

Comment 2 Mikhail Novosyolov 2024-03-30 17:27:45 MSK

The previousd maintainer of xz has made a post: https://tukaani.org/xz-backdoor/

Comment 3 Giovanni Mariani 2024-03-30 17:42:29 MSK

(In reply to Mikhail Novosyolov from comment #1)
> I also thought about rolling back to the last 5.4.x version released by the
> previous upstream maintainer, but cannot find many advantages of doing so
> after you switched to a gz tarball without that malicious script instead of
> xz.
This is what I concluded after reading the original report and the two summaries I listed... unfortunately we cannot be sure that is enough from a security POV.

> It is not clear what we will do further after rolling back. Of course, we
> will rebuild all cosumers of the library to solve problems with symbols.
Since by rolling back we have to leave out a couple of years worth of development and fixes, there is also the issue of packages using stuff that was not present in the safe release we will eventually use... I fear that a simple rebuild will be not enough.

> Maybe also remove malicious test files in %prep to make sure that they are
> not used anyhow during the build?
Tried locally before committing on ABF: removing only the two fake test files makes the %check to fail, but I did not find them listed in the test.sh script...
So I did not investigate further and simply used the sources without the evil script...

Comment 4 Mikhail Novosyolov 2024-03-30 17:48:37 MSK

A very interesting commit has been commited 2 hours ago:

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00

mikhailnov@hp-xfce /mnt/dev/sources/xz (master) $ git show 328c52da8
mikhailnov@hp-xfce /mnt/dev/sources/xz (master) $ git blame CMakeLists.txt | grep 'void my_sandbox(' -C3
328c52da8 (Jia Tan       2024-02-26 23:02:06 +0800 1002)         #include <sys/syscall.h>
328c52da8 (Jia Tan       2024-02-26 23:02:06 +0800 1003)         #include <sys/prctl.h>
f9cf4c05e (Lasse Collin  2024-03-30 14:36:28 +0200 1004) 
328c52da8 (Jia Tan       2024-02-26 23:02:06 +0800 1005)         void my_sandbox(void)
328c52da8 (Jia Tan       2024-02-26 23:02:06 +0800 1006)         {
328c52da8 (Jia Tan       2024-02-26 23:02:06 +0800 1007)             (void)prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
328c52da8 (Jia Tan       2024-02-26 23:02:06 +0800 1008)             (void)SYS_landlock_create_ruleset;

Comment 5 Giovanni Mariani 2024-03-30 21:46:45 MSK

Other options for resolving:
* fork with new name:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024#62

* (From Hacker News): xz worked fine 2 years ago. Roll back to 5.3.1 and apply a fix for the 1 security hole that was fixed since that old version. (ZDI-CAN-16587) - NOTE by me: does this solve the missing symbols problem?

Comment 6 Giovanni Mariani 2024-03-31 17:47:24 MSK

Description of the back-door and its inner workings:
https://github.com/Midar/xz-backdoor-documentation/wiki

Comment 7 Giovanni Mariani 2024-04-03 18:31:23 MSK

Mikhail, you changed the configure options to make sure landlock support is always enabled...

Unfortunately the evil commit disabling it for cmake also touched configure.ac
(see: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7).. are you sure that the little C program used for testing is OK and that landlock support is really enabled by simply passing "--enable-sandbox=landlock" to configure?

On my local system this option makes the build to fail because missing landlock support, but doing a "dmesg |grep landlock" returns "landlock: Up and running." so it should be OK on my kernel...