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.
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.
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…
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.
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
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.
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.
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.”
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
You finally got one thing right. Look up, I posted that Arch advisory that you’re quoting and told you to read it. Your response was to post an openSUSE advisory telling people to reinstall their system. That is worse than useless information for Arch/Manjaro users and that’s why I got annoyed.
The exploit hasn’t been fully analysed by anyone yet. What is known so far is that it seems to specifically target sshd and distros which build rpm/deb packages. Anyone can read the unobfuscated autoconf script that activates the exploit and confirm those findings for themselves. It is very unlikely that Arch/Manjaro is affected, but no-one knows 100% yet so it was patched on Arch “out of an abundance of caution”.
Advice for distros which were known to be targetted and known to link the exploit code into sshd is very different, and posting it here is just scaremongering.
In the longer term all of Jia Tan’s code does need to be removed, but right now there is no evidence to show that code does anything except very patiently lay the groundwork for the exploit itself.
that will be tough while still a lot of infrastructure relies on the compression-format. we’ll see what happens but these eastern won’t be forgotten by a lot of maintainers and programmers that have to fix it now.
