Xz package contains a vulnerability

Support Software & Applications
13

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
14

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

15

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
16

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
17

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
18

And do you understand why they are recommending that?

19

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

20

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 )

21

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:

22

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.

5 Likes
23

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
24

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.

25

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

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.

27

Before you slip into a coma

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.
– Arch Linux - News: The xz package has been backdoored

It would seem to be an attack on the supply chain - and there is very few actors with resources big enough to influence an otherwise reputed and respected developer.

This is one of the reasons why the denomination Reproducible Builds is a thing

Arch Linux is currently working on making all packages reproducible. This lets users and researchers verify the distributed packages from Arch Linux. For the exact definition of reproducible builds and its benefits take a look at the project website.
– Reproducible builds - ArchWiki

Why does it matter?

Whilst anyone may inspect the source code of free and open source software for malicious flaws, most software is distributed pre-compiled with no method to confirm whether they correspond.

This incentivises attacks on developers who release software, not only via traditional exploitation, but also in the forms of political influence, blackmail or even threats of violence.

This is particularly a concern for developers collaborating on privacy or security software: attacking these typically result in compromising particularly politically-sensitive targets such as dissidents, journalists and whistleblowers, as well as anyone wishing to communicate securely under a repressive regime.

Whilst individual developers are a natural target, it additionally encourages attacks on build infrastructure as a successful attack would provide access to a large number of downstream computer systems. By modifying the generated binaries here instead of modifying the upstream source code, illicit changes are essentially invisible to its original authors and users alike.

The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process. By promising identical results are always generated from a given source, this allows multiple third parties to come to a consensus on a “correct” result, highlighting any deviations as suspect and worthy of scrutiny.

This ability to notice if a developer or build system has been compromised then prevents such threats or attacks occurring in the first place, as any compromise can be quickly detected. As a result, front-liners cannot be threatened/coerced into exploiting or exposing their colleagues.

– https://reproducible-builds.org/

https://git.tukaani.org/

6 Likes
28

I read in xz Package Backdoor / Announcements, Package & Security Advisories / Arch Linux Forums :
“The xz PKGBUILD needs to be updated again, because it won’t work anymore as it goes to the dead Github repository. Preferably replaced by an older version before Jia Tan took over; something in the 5.4.x series… as to how you get access to that? Not sure which mirror.”

29

1 Like
30

this was too easy how the system got affected and there is no guarantee that similar hacks get popular and i doubt that a 100% securitycheck is possible.
btw. even distros like fedora and ubuntu are checking their systems and it was simple luck that arch/manjaro is using a different way of operation that it wasn’t affected (what still has to be prooven) and it’s still questionable if there are more packages infected by the hackers.

the link below directs to a small shell script that you can use to check if you’re affected.
Note: this is no guarantee that the malware has still some functions that are not detected till now.

#!/bin/bash

# script to detect CVE-2024-3094

# original script:
# https://www.openwall.com/lists/oss-security/2024/03/29/4

# modified (fixed and features added) by cyclone
# https://github.com/cyclone-github/scripts/blob/main/xz_cve-2024-3094-detect.sh

# tested on debian

# https://nvd.nist.gov/vuln/detail/CVE-2024-3094
# https://github.com/advisories/GHSA-rxwq-x6h5-x525

# v1.0.1; 2024-03-29

set -eu

echo "Checking system for CVE-2024-3094 Vulnerability..."
echo "https://nvd.nist.gov/vuln/detail/CVE-2024-3094"

# find path to liblzma used by sshd
# adapted from https://www.openwall.com/lists/oss-security/2024/03/29/4
sshd_path=$(whereis -b sshd | awk '{print $2}')
path=$(ldd "$sshd_path" 2>/dev/null | grep -o '/.*liblzma[^ ]*' | head -1)

if [ -z "$path" ]; then
    echo
    echo "Probably not vulnerable (liblzma not found)"
    exit
fi

# check for function signature
# adapted from https://www.openwall.com/lists/oss-security/2024/03/29/4
echo
echo "Checking for function signature in liblzma..."
if hexdump -ve '1/1 "%.2x"' "$path" | grep -q 'f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410'; then
    echo "Function signature in liblzma: VULNERABLE"
else
    echo "Function signature in liblzma: OK"
fi

# check xz version
echo
echo "Checking xz version..."
xz_version=$(xz --version | head -n1 | awk '{print $4}')
if [[ "$xz_version" == "5.6.0" || "$xz_version" == "5.6.1" ]]; then
    echo "xz version $xz_version: VULNERABLE"
else
    echo "xz version $xz_version: OK"
fi
1 Like
31

Ping? The binary packages seem to be on the ALARM mirrors now:

I can download the files from those links. But they have not reached Manjaro ARM yet.

32

Please - give the man a break … :bed:

2 Likes