xz Package Backdoor

andreyv · 2024-03-31 12:55:17

Trilby wrote:

What do you mean it hasn't been fixed. It HAS been fixed, and HAD BEEN fixed at least a day before you even posted that link. Are you even looking at this thread?

The advisory is wrong, in fact. It says "The problem has been fixed upstream in version 5.6.1". No, upstream did not fix it. Upstream is the bad actor.

Further it says "we advise users to avoid the vulnerable code in their system". However, the code in 5.6.1-2 is exactly the same as in 5.6.1-1.

Also, Arch is shipping the problem mentioned here even now.

progandy · 2024-03-31 13:05:41

andreyv wrote:

The advisory is wrong, in fact. It says "The problem has been fixed upstream in version 5.6.1". No, upstream did not fix it. Upstream is the bad actor.
Further it says "we advise users to avoid the vulnerable code in their system". However, the code in 5.6.1-2 is exactly the same as in 5.6.1-1.
Also, Arch is shipping the problem mentioned here even now.

That phrase "fixed upstream" is clearly wrong, but according to current research, there is no known vulnerability in the arch package.
5.6.1-2 and 5.6.1-1 are the same because the backdoor was most likely never compiled in the arch package, only in .deb and .rpm builds.
The CMakeLists sabotage is currently not relevant for arch as the package uses the autotool makefiles and not cmake.

There may still be undiscovered vulnerabilities, but the known ones do not impact arch linux.

As a general hardening of build processes, maybe blobs and other test files should be separated and made inaccessible during build and only usable during the test phase. The build output should be read-only during that phase.

Last edited by progandy (2024-03-31 13:10:49)

ignuthat · 2024-03-31 13:16:39

ldarby wrote:

https://git.tukaani.org should be an exact copy of the github git repo, I'd be happy with an old version of either, the problem is that https://git.tukaani.org has commits from Jia such as this one: https://git.tukaani.org/?p=xz.git;a=com … 2c422d9ba7 (which Lasse fixed in the latest commit (edit, this: https://git.tukaani.org/?p=xz.git;a=com … 1b55823b00), calling that "sabotage"). Hence I want a release that hasn't been touched by Jia. Yes maybe it's possible that Jia modified the tarballs of the earlier versions on github, before distros compiled them, but I believe it's unlikely they did that.
2nd edit, according to https://gitlab.archlinux.org/archlinux/ … f9e9b52e22, it looks like 5.2.10 was compiled from tarballs signed by Jesse edit: Lasse, not Jia (who was added here: https://gitlab.archlinux.org/archlinux/ … a5c769def6), hence looks like it's not possible at all that Jia affected this package.

Thanks for that. 5.4.2 should be a safe release tarball-wise, as it was signed with Lasse's key. 5.2.10 if you want to make absolutely sure there are no vulnerabilities introduced by Jia, but I don't know if that would break any programs that depend on xz.

As you say, Jia has probably touched other corners of the code in undesirable ways, and we'll likely find this out over the course of the next few weeks. Disabling the landlock sandbox is benign afaik, but there could be worse things we don't know about yet. We should assume there are worse things we don't know about yet.

I am reasonably sure Jia would not have been able to introduce malware without Lasse noticing, but he could absolutely do it in tarballs that Lasse and distributions aren't analyzing. Is it likely? I don't know, but it's a risk.

For Arch users, these seem like the reasonable options:

1. Upgrade to the 5.6.1-2 release, which doesn't have the SSH backdoor, but does disable the landlock sandbox and possibly more.
2. Downgrade to 5.4.2, the last release signed by Lasse. It shouldn't break anything, and the tarball is safe.
3. Downgrade to 5.2.10 to avoid any vulnerabilities Jia may have introduced earlier. I'm not sure when exactly Jia's involvement starts, but I'm trusting that you've got it right.

What you shouldn't do is downgrade to any release after 5.4.2. Those are based on tarballs created by Jia.

Scimmia · 2024-03-31 13:21:31

There's a debian ticket saying 5.3.1 is before the bad actor contributed, if that's the case, we shouldn't need to go back to 5.2.

https://bugs.debian.org/cgi-bin/bugrepo … ug=1068024

ldarby · 2024-03-31 13:23:06

Yes but there are no builds of 5.3.1 in https://archive.archlinux.org/packages/x/xz/, that's the only reason I went with 5.2.10.

Succulent of your garden · 2024-03-31 13:23:23

After reading all the thread I have three questions:

1) So in Arch repositories the xz 5.6.1-2 package was compiled with the github code and not using the tar files which have the files to make the backdoor work?

2) Does version 5.4.6 APIs still works with current Arch systems ? It seem it does by the comments, but someone has been able to fully test the API compabilities ?

3) Does OpenBsd uses xz also ? In a quick search it seems free bsd comes by default, but I'm not so sure if OpenBsd comes with xz by default. If I'm not wrong, pacman uses xz as a dependency. But it is a good idea to change this dependency by another one (I'm not completely aware of how pacman works like a dev) ? Some years ago openssl has a 10/10 cvs and the temporary solution was a downgrade or switch to libressl (OpenBsd version) in some linux distros. I fully aware that maybe this is not posible, but since nobody is writing this idea I'm current posting this as a posible solution for the people who are still worried and are elite wizzards to make that happen.

Last edited by Succulent of your garden (2024-03-31 13:23:45)

Head_on_a_Stick · 2024-03-31 13:29:50

Succulent of you garden wrote:

Does OpenBsd uses xz also ?

Not in the base system. It's available in ports though: https://github.com/openbsd/ports/tree/m … chivers/xz

ldarby · 2024-03-31 13:57:58

ignuthat wrote:

I am reasonably sure Jia would not have been able to introduce malware without Lasse noticing, but he could absolutely do it in tarballs that Lasse and distributions aren't analyzing. Is it likely? I don't know, but it's a risk.

To be clear, Jia did manage to insert the malware into the git tree under Lasse's nose, in this commit: https://git.tukaani.org/?p=xz.git;a=com … 1e274f63c0. The tarballs only contained the activation code for it. If that tarball route wasn't available, I'm absolutely sure Jia would have figured out some other way of activating it that was present in git. E.g. migrate to cmake, and during that migration, hide the equivalent lines in the first import of CMakeLists.txt. Edit: the fact that it was Lasse who commited CMakeLists.txt in 2020 is not relevant at all to the point I'm making, which is that Jia would have figured something else out.

Last edited by ldarby (2024-03-31 14:06:32)

ewaller · 2024-03-31 14:17:34

This thread had been meant to call attention to the official announcement. I think it is clear systems should be updated out of caution. This thread has diverged from that point.
I am going to go ahead and close the thread at this point.

Arch Linux

#51 2024-03-31 12:55:17

Re: xz Package Backdoor

#52 2024-03-31 13:05:41

Re: xz Package Backdoor

#53 2024-03-31 13:16:39

Re: xz Package Backdoor

#54 2024-03-31 13:21:31

Re: xz Package Backdoor

#55 2024-03-31 13:23:06

Re: xz Package Backdoor

#56 2024-03-31 13:23:23

Re: xz Package Backdoor

#57 2024-03-31 13:29:50

Re: xz Package Backdoor

#58 2024-03-31 13:57:58

Re: xz Package Backdoor

#59 2024-03-31 14:17:34

Re: xz Package Backdoor

Board footer