For what it’s worth, ldd `which sshd` does not include liblzma on Manjaro ARM (presumably also not on Manjaro x86), so at least the packaged sshd is not affected by the backdoor.
It seems so.
2 Likes
i’v done the update as demanded with
sudo pacman -Syu
it’s update installed
lib32-xz-5.6.1-2
BUT
xz 5.6.0-1 [Installiert]
6.5.0-1 is still installed and not updated. did i miss something or do have to worry ?
p.s.: i’m on stable branch
1 Like
Next time, try using that word in a complete sentence instead of a large, standalone banner. 
Not all mirrors have synced yet. You could always try refreshing your mirrors.
i’m not seeing where any of the mirrors were updated - those updated most recently are still carrying xz 5.6.0
1 Like
Sorry guys, I made a mistake pushing xz 5.6.1-2. It will actually be available in testing & stable shortly.
6 Likes
only affects debian / rpm distributions
Also, almost everything I’ve been reading implies that it is just OpenSSH that is effected. If that is the case, then the sky isn’t falling, but there sure are a lot of packages that rely on xz.
2 Likes
i’m not sure about that - many distros are listed here, Manjaro among them…
also, emphasis added…
CVE-2024-3094- Red Hat Customer Portal
Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.
…and now i see 5.6.1 is being pushed to the repos, however it seems that contains the malicious code also???
XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access - Phoronix
XZ 5.6 debuted one month ago and XZ 5.6.1 came out three weeks ago. As of writing, no XZ 5.6.2 or similar released version is yet available with the malicious code removed.
admittedly i’m the dummy here, but it looks to me like this is not distro dependent
5.6.1-2 is the fixed version.
Anything below that, and beginning with 5.6.0, is affected. So…
5.6.0 - 5.6.1-1 = 
5.6.1-2 = 
8 Likes
It’s very simple, just read the official Arch Linux post that @Yochanan linked above instead of random sites.
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)"However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.
5 Likes
redhat and phoronix aren’t random sites, and as it says in the arch post…
This is because other yet-to-be discovered methods to exploit the backdoor could exist.
openSUSE is recommending a reinstall…
openSUSE addresses supply chain attack against xz compression library - openSUSE News
For our openSUSE Tumbleweed users where SSH is exposed to the internet we recommend installing fresh, as it’s unknown if the backdoor has been exploited. Due to the sophisticated nature of the backdoor an on-system detection of a breach is likely not possible.
1 Like
And do you understand why they are recommending that?
can’t say i do, but i’m reading through this and trying to understand better…
[Bug]: Upstream compromised? Or is the compromise? · Issue #92 · tukaani-project/xz · GitHub
ew, UTC-induced casual racism all over that thread 
( as usual, also accompanied by other enlightened thoughts such as timezone of commit is infallible )
The Hacker News thread is a fascinating read.
This was a very sophisticated compromise done over a long period of time. They even got a PR into Google’s oss-fuzz project - xz: Disable ifunc to fix Issue 60259. by JiaT75 · Pull Request #10667 · google/oss-fuzz · GitHub.
Can’t say I’m suprised. Do you understand this sentence?
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible
Do you understand how that differs from openSUSE’s advisory?
Current research indicates that the backdoor is active in the SSH Daemon
Do you understand that Arch and openSUSE are not the same thing? 
is **most likely** not vulnerable, as the backdoor **appears** to only run when built by the Debian build system or as an RPM package. Regardless, **it's probably sensible to revert to the last known good release**
Just some observations from actually reading the Arch Linux post in Gitlab. I think your tone and obvious sarcasm fall short of the expected courtesy.
4 Likes
have you looked at the code? do you know exactly what it does, how it does it and what other packages may be affected?
you and your sarcasm can both take a long walk off the proverbial short pier
1 Like
Yes. Have you? Do have any clue at all what you’re talking about? The evidence so far suggests not. So why not leave off the headless chicken panic posting.
glad we have an expert on scene
unfortunately the boys at Arch don’t seem to completely agree - perhaps you can straighten them out too, eh?
emphasis mine…
TL;DR: Upgrade your systems and container images now!
However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.
seems the discoverer doesn’t agree with you either - again, emphasis mine…
[oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise [LWN.net]
I’d upgrade any potentially vulnerable system ASAP.
== Bug reports ==
Given the apparent upstream involvement I have not reported an upstream bug. As I initially thought it was a debian specific issue, I sent a more preliminary report to security@debian.org. Subsequently I reported the issue to distros@. CISA was notified by a distribution.
[PATCH 01/11] MAINTAINERS: Add XZ Embedded maintainers - Lasse Collin
I have been the maintainer of the upstream project since I submitted
the code to Linux in 2010 but I forgot to add myself to MAINTAINERS.
Nowadays Jia Tan is the other maintainer.
the point i’m making here is that no one, including yourself, knows yet the full scope of the issue or how much damage commits by Jia Tan have caused to Linux based systems
xz-utils backdoor situation · GitHub
We’re reasonably sure the following things need to be true for your system to be vulnerable:
- You need to be running a distro that uses glibc (for IFUNC)
- You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) - likely only true if running a rolling-release distro and updating religiously.
i’m convinced that this issue must be part of a intense investigation. seems this developer has been involved in a lot of projects and it’s a question if he was part of the attack or if he had been also a victim of this attack. sad but this seems not to be a security issue through an programming mistake but a offensive attack of someone who wanted to gain access in a criminal intension and from what i can understand this backdoor had been active for longer now.