xz Package Backdoor

whatshisname · 2024-03-30 15:59:31

Cutting to the chase, is upgrading to xz-5.6.1-2-x86_64 that dropped today sufficient to dodge this vulnerability?

Scimmia · 2024-03-30 16:00:53

Yet again, Arch was never vulnerable.

bsdice · 2024-03-30 16:29:16

Need to wait for analysis of the 88 KB blob. I am also not yet convinced Arch is unaffected, due to the convoluted mess of commits of this (my educated guess) state actor. Build scripts and edits in those are one big jungle. Have to wait for reverse engineering of the blobs.

Scimmia · 2024-03-30 16:30:52

bsdice wrote:

Need to wait for analysis of the 88 KB blob. I am also not yet convinced Arch is unaffected, due to the convoluted mess of commits of this (my educated guess) state actor. Build scripts and edits in those are one big jungle. Have to wait for reverse engineering of the blobs.

The blob in question here was never included in the Arch package. Yes, there could be other unknown issues, but we're dealing with what's known right now in this thread.

ldarby · 2024-03-30 19:03:29

ignuthat wrote:

For now, I'm taking some extra precaution by downgrading to the 5.4.6 version of xz on Arch

Did you find any problems doing this? I've now downgraded to 5.2.10 from here: https://archive.archlinux.org/packages/ … kg.tar.zst (latest version in the repo before 5.3) and haven't found any issues yet, ldd shows everything in my /bin and /usr/lib just links to /usr/lib/liblzma.so.5, with no errors.

~~This is missing the later legit security fixes in xz, but I'm happier to live without those for now.~~ edit: nope, CVE-2022-1271 was fixed in 5.2.5-3, and it looks like that was the only one.

Last edited by ldarby (2024-03-30 19:54:01)

ugjka · 2024-03-30 19:34:38

Now i wish there was a rust rewrite drop in replacement for this xz nonsense...

Alad · 2024-03-30 22:44:44

Things are even worse with Rust:

#archlinux-projects wrote:

<freswa> svenstaro You can just say RiiR. It’s fine.
<CounterPillow> then you can have 300 supply chain compromises instead of just 1
<svenstaro|M> I'll be honest, I'm really quite worried for Rust too as this kind of thing would be all too easy there as well. Especially given build.rs and how crates.io doesn't need to follow GitHub tags.
<abby> you could always not use cargo, à la mesa
<svenstaro|M> That seems like the wrong solution
<anthraxx|M> svenstaro|M: well its a maintenance clusterfuck, but i do see how debians approach for rust has easier way to just build everything including dependencies from version control
<svenstaro|M> This is the one thing I think go does right
<svenstaro|M> Crates.io should disable releases without a scm tag

Last edited by Alad (2024-03-30 22:45:21)

OpusOne · 2024-03-30 23:49:03

Well, yes. But the current xz package (5.6.1-2) is still based on the following upstream URL: https://xz.tukaani.org/xz-utils/
which has also been taken down.
So, that makes no sense.
Unless I'm the only one that sees this URL as dead.
Perplexed.

seth · 2024-03-30 23:56:59

https://git.tukaani.org/ is still there but xz.tukaani.org has been taken out of DNS it seems.

OpusOne · 2024-03-31 00:00:47

seth wrote:

https://git.tukaani.org/ is still there but xz.tukaani.org has been taken out of DNS it seems.

Yes, but just look at the official xz package.
https://archlinux.org/packages/core/x86_64/xz/

The upstream URL is down, so strictly speaking, the xz package should be flagged out-of-date. But yes, the source in the PKGPBUILD is from git.tukaani.org.
I guess the "url" field is just a reference and plays no actual role in the package itself, but it's become invalid. Maybe just a detail.

Last edited by OpusOne (2024-03-31 00:03:24)

ldarby · 2024-03-31 00:04:46

The

source

line was updated here: https://gitlab.archlinux.org/archlinux/ … 00569804c9

And https://tukaani.org/xz-backdoor/ says

The XZ projects currently don’t have a home page

so there's nothing to change the

url

line to yet.

OpusOne · 2024-03-31 00:29:40

I understand. Maybe the git repo url could be put there instead: https://git.tukaani.org/ , until the project gets back a home page. If it does.
But again, that's probably just a detail.

ignuthat · 2024-03-31 02:43:58

ldarby wrote:

Did you find any problems doing this? I've now downgraded to 5.2.10 from here: https://archive.archlinux.org/packages/ … kg.tar.zst (latest version in the repo before 5.3) and haven't found any issues yet, ldd shows everything in my /bin and /usr/lib just links to /usr/lib/liblzma.so.5, with no errors.
~~This is missing the later legit security fixes in xz, but I'm happier to live without those for now.~~ edit: nope, CVE-2022-1271 was fixed in 5.2.5-3, and it looks like that was the only one.

I didn't have any problems downgrading to 5.4.2, which is what Gentoo downgraded to. However, I did just realize that this could be a bad idea if you don't go back far enough.

Many of the release tarballs were created by Jia Tan, which as we know, contained a vulnerability that was not present in the git repository. The tarballs are extra-not-trustworthy. All previous Arch packages for xz were built from the tarballs, until 5.6.1-2.

So you would want to make sure you were going back to a tarball created and signed by Lasse. How to verify that? Not sure.

So it may be safer to stick with the 5.6.1-2 package, which we know Arch has built directly from the git repository.

Edit: Though it's also worth considering that Jia Tan had control of Github, but not git.tuukani.org, which Lasse remained in control of: https://tukaani.org/xz-backdoor/

The current 5.6.1-2 package is built from the Github repository (disabled), not git.tuukani.org, despite the PKGBUILD being updated.

Last edited by ignuthat (2024-03-31 09:46:25)

ujione · 2024-03-31 06:09:31

i just wondering, how this important package maintain by just one person

ignuthat · 2024-03-31 06:28:10

ujione wrote:

i just wondering, how this important package maintain by just one person

It's not the only important software that is thanklessly maintained by one person in their spare time as a passion project. You'll find it's a common problem with open source software (OpenSSL comes to mind).

Fuxino · 2024-03-31 08:49:10

ujione wrote:

i just wondering, how this important package maintain by just one person

Relevant xkcd: https://xkcd.com/2347/

millus · 2024-03-31 09:24:11

Sorry, this is from 2016 or so, so probably already known to everyone. I'd still like to mention it, in case anyone didn't read it yet, about xz from an lzip author:
https://www.nongnu.org/lzip/xz_inadequate.html

Awebb · 2024-03-31 10:09:49

millus wrote:

Sorry, this is from 2016 or so, so probably already known to everyone. I'd still like to mention it, in case anyone didn't read it yet, about xz from an lzip author:
https://www.nongnu.org/lzip/xz_inadequate.html

Relevance?

millus · 2024-03-31 10:41:33

Awebb wrote:

millus wrote:
Sorry, this is from 2016 or so, so probably already known to everyone. I'd still like to mention it, in case anyone didn't read it yet, about xz from an lzip author:
https://www.nongnu.org/lzip/xz_inadequate.html
Relevance?

It explains (from the author's pov) why using xz is a bad idea in general. So if it's dangerous and bad, that could reach the threshold for a decision of discarding it altogether.
And of course if the author's claims had been agreed to and acted upon, the scale of this backdoor-issue today would be smaller than it is, as to which extent is spectulation, perhaps not even exist though.

Last edited by millus (2024-03-31 10:54:25)

ooo · 2024-03-31 10:47:08

Bit confused about this part in the official announcement:

archlinux.org wrote:

From the upstream report (one):
openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:
ldd "$(command -v sshd)"

So, according to the upstream report, the attack vector uses patched libsystemd notification support in openssh, and openssh never directly uses liblzma.
Then, the suggestion to use lld to confirm that the arch sshd does not use liblzma seems irrelevant. It would make more sense to check that openssh does not link to libsystemd, right?

Is this just a mistake in the announcement or am I missing something?

EDIT:
In case you were wondering:

$ ldd "$(command -v sshd)" | grep systemd | wc -l
0

Last edited by ooo (2024-03-31 10:50:11)

ldarby · 2024-03-31 10:50:50

ignuthat wrote:

ldarby wrote:
Did you find any problems doing this? I've now downgraded to 5.2.10 from here: https://archive.archlinux.org/packages/ … kg.tar.zst (latest version in the repo before 5.3) and haven't found any issues yet, ldd shows everything in my /bin and /usr/lib just links to /usr/lib/liblzma.so.5, with no errors.
~~This is missing the later legit security fixes in xz, but I'm happier to live without those for now.~~ edit: nope, CVE-2022-1271 was fixed in 5.2.5-3, and it looks like that was the only one.
I didn't have any problems downgrading to 5.4.2, which is what Gentoo downgraded to. However, I did just realize that this could be a bad idea if you don't go back far enough.
Many of the release tarballs were created by Jia Tan, which as we know, contained a vulnerability that was not present in the git repository. The tarballs are extra-not-trustworthy. All previous Arch packages for xz were built from the tarballs, until 5.6.1-2.
So you would want to make sure you were going back to a tarball created and signed by Lasse. How to verify that? Not sure.
So it may be safer to stick with the 5.6.1-2 package, which we know Arch has built directly from the git repository.
Edit: Though it's also worth considering that Jia Tan had control of Github, but not git.tuukani.org, which Lasse remained in control of: https://tukaani.org/xz-backdoor/
The current 5.6.1-2 package is built from the Github repository (disabled), not git.tuukani.org, despite the PKGBUILD being updated.

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.

Last edited by ldarby (2024-03-31 11:58:26)

ldarby · 2024-03-31 11:21:18

ooo wrote:

So, according to the upstream report, the attack vector uses patched libsystemd notification support in openssh, and openssh never directly uses liblzma.
Then, the suggestion to use lld to confirm that the arch sshd does not use liblzma seems irrelevant. It would make more sense to check that openssh does not link to libsystemd, right?

No, in theory systemd could be built to not link to liblzma, and that sshd links to liblzma for a different reason that doesn't involve systemd, and it'd still be vulnerable. All that matters is it liblzma gets loaded, and libsystemd is just one known (so far) mechanism that loads it (also note, it's possible for programs to dlopen() libs at run time, so if sshd dlopened liblzma (or libsystemd) then it'd it still be vulnerable without ldd showing that. I assume you can also use LD_PRELOAD to load the payload as well).

ldarby · 2024-03-31 11:53:20

Just noticed that Jesse's edit: Lasse's key in Arch, here: https://gitlab.archlinux.org/archlinux/ … type=heads has expired. The maintainers / security team will need to take care of this

Are they even looking at this thread? The mistake I pointed out in https://security.archlinux.org/ASA-202403-1 still hasn't been fixed. I get that there was a world -wide major panic while that being written, but it can and should still be fixed afterwards.

Last edited by ldarby (2024-03-31 11:58:52)

Trilby · 2024-03-31 12:46:44

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?

ldarby · 2024-03-31 12:49:49

I'm talking about this mistake, which has not been fixed:

The problem has been fixed upstream in version 5.6.1.

It is a false statement. The problem has in fact not been fixed in upstream 5.6.1.

Arch Linux

#26 2024-03-30 15:59:31

Re: xz Package Backdoor

#27 2024-03-30 16:00:53

Re: xz Package Backdoor

#28 2024-03-30 16:29:16

Re: xz Package Backdoor

#29 2024-03-30 16:30:52

Re: xz Package Backdoor

#30 2024-03-30 19:03:29

Re: xz Package Backdoor

#31 2024-03-30 19:34:38

Re: xz Package Backdoor

#32 2024-03-30 22:44:44

Re: xz Package Backdoor

#33 2024-03-30 23:49:03

Re: xz Package Backdoor

#34 2024-03-30 23:56:59

Re: xz Package Backdoor

#35 2024-03-31 00:00:47

Re: xz Package Backdoor

#36 2024-03-31 00:04:46

Re: xz Package Backdoor

#37 2024-03-31 00:29:40

Re: xz Package Backdoor

#38 2024-03-31 02:43:58

Re: xz Package Backdoor

#39 2024-03-31 06:09:31

Re: xz Package Backdoor

#40 2024-03-31 06:28:10

Re: xz Package Backdoor

#41 2024-03-31 08:49:10

Re: xz Package Backdoor

#42 2024-03-31 09:24:11

Re: xz Package Backdoor

#43 2024-03-31 10:09:49

Re: xz Package Backdoor

#44 2024-03-31 10:41:33

Re: xz Package Backdoor

#45 2024-03-31 10:47:08

Re: xz Package Backdoor

#46 2024-03-31 10:50:50

Re: xz Package Backdoor

#47 2024-03-31 11:21:18

Re: xz Package Backdoor

#48 2024-03-31 11:53:20

Re: xz Package Backdoor

#49 2024-03-31 12:46:44

Re: xz Package Backdoor

#50 2024-03-31 12:49:49

Re: xz Package Backdoor

Board footer