You are not logged in.

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

whatshisname
Member
Registered: 2010-04-24
Posts: 163

Re: xz Package Backdoor

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

Offline

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

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,107

Re: xz Package Backdoor

Yet again, Arch was never vulnerable.

Offline

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

bsdice
Member
Registered: 2016-08-06
Posts: 14

Re: xz Package Backdoor

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.

Offline

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

Scimmia
Fellow
Registered: 2012-09-01
Posts: 12,107

Re: xz Package Backdoor

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.

Offline

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

ldarby
Member
From: UK
Registered: 2024-03-29
Posts: 14

Re: xz Package Backdoor

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)

Offline

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

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,863
Website

Re: xz Package Backdoor

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


https://ugjka.net
paru > yay | vesktop > discord
pacman -S spotify-launcher
mount /dev/disk/by-...

Offline

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

Alad
Wiki Admin/IRC Op
From: Bagelstan
Registered: 2014-05-04
Posts: 2,418
Website

Re: xz Package Backdoor

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 big_smile
<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)


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby

Offline

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

OpusOne
Member
Registered: 2023-05-31
Posts: 139

Re: xz Package Backdoor

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.

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 58,967

Re: xz Package Backdoor

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

Online

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

OpusOne
Member
Registered: 2023-05-31
Posts: 139

Re: xz Package Backdoor

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)

Offline

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

ldarby
Member
From: UK
Registered: 2024-03-29
Posts: 14

Re: xz Package Backdoor

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.

Offline

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

OpusOne
Member
Registered: 2023-05-31
Posts: 139

Re: xz Package Backdoor

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.

Offline

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

ignuthat
Member
Registered: 2022-03-23
Posts: 18

Re: xz Package Backdoor

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)

Offline

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

ujione
Member
From: Yogyakarta
Registered: 2024-03-30
Posts: 2
Website

Re: xz Package Backdoor

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


Aplikasi Ujian Online Berbasi Cloud

Offline

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

ignuthat
Member
Registered: 2022-03-23
Posts: 18

Re: xz Package Backdoor

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).

Offline

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

Fuxino
Member
From: Slovakia
Registered: 2014-09-26
Posts: 197

Re: xz Package Backdoor

ujione wrote:

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

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


Arch + XMonad

Dotfiles: https://github.com/Fuxino/dotfiles

Offline

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

millus
Member
Registered: 2019-07-21
Posts: 220

Re: xz Package Backdoor

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

Offline

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

Awebb
Member
Registered: 2010-05-06
Posts: 6,613

Re: xz Package Backdoor

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?

Offline

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

millus
Member
Registered: 2019-07-21
Posts: 220

Re: xz Package Backdoor

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)

Offline

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

ooo
Member
Registered: 2013-04-10
Posts: 1,638

Re: xz Package Backdoor

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)

Offline

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

ldarby
Member
From: UK
Registered: 2024-03-29
Posts: 14

Re: xz Package Backdoor

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)

Offline

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

ldarby
Member
From: UK
Registered: 2024-03-29
Posts: 14

Re: xz Package Backdoor

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).

Offline

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

ldarby
Member
From: UK
Registered: 2024-03-29
Posts: 14

Re: xz Package Backdoor

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)

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 30,330
Website

Re: xz Package Backdoor

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?


"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman

Offline

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

ldarby
Member
From: UK
Registered: 2024-03-29
Posts: 14

Re: xz Package Backdoor

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.

Offline

Board footer

Powered by FluxBB