Xz package contains a vulnerability

I’m not really sure where to post this, as I haven’t found a dedicated Security topic, but it turns out, the xz package contains a vulnerability.

Phoronix: https://www.phoronix.com/news/XZ-CVE-2024-3094
Red Hat: Urgent security alert for Fedora 41 and Fedora Rawhide users
Debian: [SECURITY] [DSA 5649-1] xz-utils security update
openSUSE has already downgraded their package: Request 1163302: Submit xz - openSUSE Build Service

Given the severity of the issue, it could be preferable to downgrade the package in Manjaro too.

Also, may I ask, where to post such security issues in the future if needed?

10 Likes

Arch already addressed it by switching the source from the release tarball to the git tag with xz 5.6.1-2. It’s currently available in the Manjaro unstable branch. I’ll fast-track it to our testing & stable branches here shortly.

EDIT: More info:

EDIT: Even more info:

https://archlinux.org/news/the-xz-package-has-been-backdoored/

16 Likes

Unfortunately, 5.6.1-2 seems to be only available on x86 at this time, is ARM going to get fixed soon?

1 Like

I don’t know much about packaging, but some people on the hackernews post claimed the backdoor only affects debian / rpm distributions because of some extra patching they do on the ssh daemon. I don’t know how to verify if these claims are true, so it’s better to wait until a manjaro maintainer confirms if we are safe or not.

1 Like

ALARM also addressed it with xz 5.6.1-2. I’ll sync Manjaro ARM unstable and also fast-track xz to testing & stable shortly.

EDIT: Waiting for the ALARM mirrors to catch up.

EDIT: Sync to ARM unstable and fast-tracking to testing & stable is done.

2 Likes

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. :wink:

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…

liblzma and xz version 5.6.0 and 5.6.1 are vulnerable to arbitrary code execution compromise - Xe Iaso

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 = :warning:

5.6.1-2 = :white_check_mark:

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 :face_vomiting:

( 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? :facepalm: