You are not logged in.
Cutting to the chase, is upgrading to xz-5.6.1-2-x86_64 that dropped today sufficient to dodge this vulnerability?
Offline
Yet again, Arch was never vulnerable.
Offline
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
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
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
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
Things are even worse with Rust:
<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)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
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
https://git.tukaani.org/ is still there but xz.tukaani.org has been taken out of DNS it seems.
Online
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
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
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
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
i just wondering, how this important package maintain by just one person
Aplikasi Ujian Online Berbasi Cloud
Offline
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
i just wondering, how this important package maintain by just one person
Relevant xkcd: https://xkcd.com/2347/
Offline
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
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
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.htmlRelevance?
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
Bit confused about this part in the official announcement:
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
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
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
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
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
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