This needs to be pinned
this post was submitted on 29 Mar 2024
369 points (99.7% liked)
Arch Linux
7777 readers
1 users here now
The beloved lightweight distro
founded 4 years ago
MODERATORS
Well did I tell you guys, I use Debian stable btw
To be fair, the backdoor only gets enabled when built as an RPM or Deb package, which doesn't apply to Arch Linux, and also requires openSSH to be linked to liblzma, which is also not the case on Arch. So from what we know so far, the Arch packages should not have had the vulnerability. The risk now is whether there are other vulnerabilities or backdoors that haven't been discovered which is why Arch made the update building directly from the git source instead of the known modified source tarball.
According to this guy Debian is the problem https://lemmy.ml/comment/9780209
Debian is not really the problem, but rather the target, just read the original announcement at https://www.openwall.com/lists/oss-security/2024/03/29/4:
== Affected Systems ==
Running as part of a debian or RPM package build:
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then
...
openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.
Initially starting sshd outside of systemd did not show the slowdown, despite
the backdoor briefly getting invoked. This appears to be part of some
countermeasures to make analysis harder.
Observed requirements for the exploit:
a) TERM environment variable is not set
b) argv[0] needs to be /usr/sbin/sshd
c) LD_DEBUG, LD_PROFILE are not set
d) LANG needs to be set
e) Some debugging environments, like rr, appear to be detected. Plain gdb
appears to be detected in some situations, but not others
So if you were using Arch, you were unaffected by this vulnerability because
- the script wouldn't trigger because it uses neither DEB nor RPM packages
- even if it had triggered, the backdoor only gets activated when the calling binary is
/usr/sbin/sshdwhich doesn't happen in Arch because they don't patch OpenSSH to support systemd (which in turn pulls in xz).
This doesn't mean that Arch saved you because it's super secure or anything, but this was a supply chain attack that hit Arch (and Debian Sid, where the backdoor was actually caught because ssh logins took so long…), but it didn't trigger because it wasn't targeted.
Meaning there's no immediate need to be concerned, but you should update ASAP even though the Arch package probably doesn't contain backdoored artifacts.
The announcement link leads to a Not Found
It just worked fine when I checked right now
Thanks for telling that means arch is not compromised as of right now.
Thanks for clarifying. I read through the original announcement but I couldn't fully understand it
Simply excluding this backdoor does not seem to be sufficient. The malicious actor has contributed over 750 commits to xz, all of which could contain further backdoors.
Downgrading to the last version without any contributions from the malicious actor is not possible either, because of new functionalities and other security issues that were fixed in the meantime. Uninstalling xz is also not possible, because half my system depends on it.
I guess it will take some time to sort all of that out. I am very impressed by the fast and coordinated response to this incident by the FOSS community.
This is just speculation, but I think this was a long planned attack. I think it's unlikely any previous backdoors or significant security vulnerabilities would have been introduced, the goal was to establish themselves as a legitimate contributor and then sneak one critical backdoor in unnoticed. Sneaking in multiple vulnerabilities would have increased the risk of detection.
From what I understand they did cause a conflict with another package, and then used that to try to justify having the backdoored versions of the package fast tracked into upcoming Debian and fedora releases. But that would also suggest that their whole goal was shipping this one backdoor.
Man, rolling release is great
I use Debian stable btw…
Why does xz exist anyway?
It provides liblzma, an implementation of the lzma compression algorithm
That's why I use dz instead. It provides ligma. It's a much better compression algorithm.
It is a compression library that is in the dependency tree for a large number of other packages though not as many as zlib which is in practically everything.
xz development appears to have been compromised by some organisation in a long game targeting sshd in Debian and derivatives. Debian maintainers have a nasty habit of adding lots of patches to upstream sources which occasionally have unintended consequences. I am a long term Debian user but I wish they would stop doing this. Thankfully arch generally doesn't modify upstream as much as Debian and arch sshd doesn't link in the backdoored library.
Ah I see. Are there any reasons why people would choose to use xz over zlib?
It compresses much better, by a lot, as zlib/deflate is an ancient algorithm made back when computers only had a few megabytes of ram.
Nowadays though, zstd seems to be replacing both of them, as at max level it compresses about as well as xz while also being faster. Nevertheless, many programs link against all the common compression algorithms (xz/zlib/zstd/bz2) to support everything
Ah I see
Thanks for the PSA.
The downside to bleeding edge…
This backdoor has existed for the past 2 months. If anything, Arch was one of the first to roll out the fix.
Sure, but if you went the Debian way of things….. you wouldn’t have had the back door version for three more years
Without knowing my arch installation has xz 5.6.1-2
I am a brand new debian user, with debian running on two active laptops (mine and my daughter's). Is this something I need to be concerned about and if so, what do I do?
Literally first week or two of use and still quite lost trying to get used to the massive difference from Windows.
If you're on Debian stable, you don't need to worry too much. This attack is actually targeted at Debian and Debian-based systems, but Debian is slow to update packages to make sure everything is stable. Thanks to this, Debian stable never updated with the infected package.
If you were on one of the Debian testing updates though your system is in danger. The other concern is that the bad user who pushed this backdoor has been providing code updates for two years. Seemingly these other updates were legitimate to get him in position to sneak in this backdoor, but there is a chance that he has already snuck in some other kind of backdoor that hasn't yet been identified and that could be present on your system.
For the time being, you're probably ok and we just need to wait to see if any other backdoors are found in the code.
Okay, thank you very much.
For Ubuntu releases, Package search shows latest versions used are 5.4.x.
Are all these releases compromised too?
Not that we know of, just package versions 5.6.0 and 5.6.1