Subject: https://openwall.com/lists/oss-security/2024/03/29/4
I guess it has something to do with sshd linking, though I'm not sure (not an expert). Today xz got updated and now I'm concerned a bit.
Any thoughts, guys?
shouldn't be an issue, as sshd is not linked against lzma
When using xz version 5.6.0-1 or 5.6.1-1, upgrading is recommended.
artist
That does sound worrying, if malevolent code has been inserted into the upstream package, from that link the affected versions are 5.6.0 and 5.6.1, the update today is just a minor version from 5.6.1-1 to 5.6.1-2 so unless it has been modified to fix this it is also suspect.
You can get the last known good version from here:
https://archive.artixlinux.org/packages/x/xz/ (https://archive.artixlinux.org/packages/x/xz/)
xz-5.4.6-1-x86_64.pkg.tar.zst 26-Jan-2024 21:02 613K
and install it with:
# pacman -U xz-5.4.6-1-x86_64.pkg.tar.zst
then add the line:
IgnorePkg = xz
to /etc/pacman.conf to stop it being upgraded for now.
That's what I've done anyway until further instructions appear! Can't be too careful with live malware exploits - thanks for the warning! :D
(From the description the code is obfuscated and the reporter was unsure exactly what it did so it might affect other aspects besides ssh operations.)
https://news.ycombinator.com/item?id=39865810
Do we need to change SSH keys?
From what I can tell, the backdoor is injected into the distributed tarballs but not the repo itself. Arch recently started pulling from the repos instead of downloading the tarball: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad
Artix too on system-gremlins: https://gitea.artixlinux.org/packages/xz/commit/7cde4de09a6f768d3ee58c5bdf02581af2f06ef8
I would suggest people install the latest system-gremlins/xz, as this doesn't yet seem to have rolled out to system.
Also, if the packagers are reading this, I suggest switching to #commit= instead of #tag= as tags can be changed
Bit ironic that the last commit (https://github.com/tukaani-project/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c), by the xz dev who it's being reported was the one who got their account compromised (assuming that's what has happened), had the message "Docs: Simplify SECURITY.md."
Edit:
The whole thing smells a bit off.
The backdoor may have only been injected into the tarballs but there's supposedly 'artifacts', as this Ars article (https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/?comments=1&comments-page=1) calls them, in the main repo which run the backdoor.
Tests: Add a few test files.
(https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0)
How do you not notice commits made in your name to master ?
on arch linux: https://archlinux.org/news/the-xz-package-has-been-backdoored/
in artix, sshd is indeed not linked against lzma, so no problem :)
you can check it with the following command:
ldd $(command -v sshd) | grep liblzma
if the check above returns empty then you're good.
When using xz version 5.6.0-1 or 5.6.1-1, upgrading is recommended.
artist
I've decided I don't trust xz at all atm, since JiaT75's first commit. (Jan 7 2023)
So I've downgraded xz to 5.4.0-1 (Build Date : Thu 15 Dec 2022)
Is this paranioa ?
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
I've no clue ? But sounds dodgy.
I'll wait for the dust to settle....
Edit: And github have just suspended the xz repo
It's not paranoia, I also don't believe that existing fixed package has 100% safe code, because that Jia Tan plant was smuggling all kind of nasty shit to several projects, not just to xz/liblzma.
https://github.com/libarchive/libarchive/pull/1609
https://github.com/google/oss-fuzz/pull/10667/
We have to wait for more of this story to unfold.
Also, keep in mind that running ldd is unsafe in some instances.
https://jmmv.dev/2023/07/ldd-untrusted-binaries.html
EDIT: Unrelated, but seems like I can't access archive.artixlinux.org without VPN? What's going on?
It's not paranoia, that's damn sad. Btw, the link shows a nice perspective of this backdoor (came here today to post it too).
The guy (Jia Tan) was also included as a maintainer of XZ Embedded repository used in the Linux kernel:
https://lore.kernel.org/lkml/
[email protected]/t/
Ha... that's what I was talking about, but was sent to the website hosting ppl first and no one took the responsibility here, with someone even stating (https://forum.artixlinux.org/index.php/topic,6252.msg39273.html#msg39273) that the war in Ukraine was the answer... Have a read here: https://forum.artixlinux.org/index.php/topic,6252.30.html
Gitea migrated to another provider and now it works. Archive only via VPN.
Update from the author: https://tukaani.org/xz-backdoor/
5.4.6 Stable is fine (https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094).
Sadly, there's more to this, and yeah guys, it's bad: https://old.reddit.com/r/linux/comments/1brhlur/xz_utils_backdoor/kx9b9wc/
And the worse thing is that we can't even bisect it properly to see which version is the one that's least likely to be less vulnerable...
Hello, I am a novice regarding topics like this, but I noticed the files in 5.6.1-1 and the fixed 5.6.1-2 are identical in /usr/bin and /usr/lib. Does this mean Artix was completely unaffected or did the old PKGBUILD somehow get built?
Also, I noticed in the .BUILDINFO the allegedly compromised version of xz was installed. Does this matter at all?
"Based on the same analysis, the execution of openssh under systemd is a prerequisite for the backdoor to activate and given the additional distance of Artix to systemd (aren't we glad?), the exploit shouldn't affect any running Artix system. "
https://artixlinux.org/
Hello. As far as I am aware, there is not yet a complete understanding if openssh is the only attack vector. The post also suggests upgrading, but upgrading results in installing identical files. Comparing md5 sums:
2a066731ba8417aa6bc88942e7be4c5c xz-5.6.1-1-x86_64.pkg/usr/lib/liblzma.so.5.6.1
2a066731ba8417aa6bc88942e7be4c5c xz-5.6.1-2-x86_64.pkg/usr/lib/liblzma.so.5.6.1
The reason I am asking is the assumption that the script only executes on deb/rpm packages only applies to 5.6.0. In 5.6.1, there are additional code that will execute upon building on any Linux distribution. Fortunately, it seems the test files it looks for don't yet exist. However, with the amount of unknowns in this situation, I am still concerned.
https://www.openwall.com/lists/oss-security/2024/03/30/15
https://gynvael.coldwind.pl/?lang=en&id=782#stage2
https://tukaani.org/xz-backdoor/
Read the gentoo and debian bug reports linked at the bottom. The consensus on those seems to be downgrading prior to the point of JiaT75's first commit or even first contributions. But if you go back past to before the first contribution that's before a security fix (ZDI-CAN-16587)
No one knows for sure atm. There's a lot of code to be checked. But I downgraded to 5.4.0-1, before their first commit and everything seems to still work ok.
I can foresee xz being expunged from the distro's and kernel in the long run. Or at least I wouldn't be surprised. It got popularity due to compression size but now zstd is better imho so it doesn't need to be so tightly integrated with everything else
Is there an alternative to the xz package? I couldn't find one from a quick search. pixz might do xz compression but it doesn't offer libs for other packages. It proves the old point about needing alternative inits, at least we have a choice in that.
For all those interested, here's some backdoor analysis and reverse engineering:
https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
and here:
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
That's some crazy geeky stuff, I should say. Made by a clever Korean dude...
https://gynvael.coldwind.pl/?lang=en&id=782
Is there any evidence for the nationality of the perpetrator,or even anything to show it was a single individual? If the ID was fake the public name is meaningless, and the true location probably disguised by vpn, if anything it would be intentionally chosen to deceive.
Incidentally, on the off topic subject of blocked access to Artix resources from certain locations, if all known paths are genuinely clear then like looking for dark matter it might indicate an invisible firewall system, China is the only country in the world known to have national firewall but you can imagine it might not be alone, perhaps they are just being more honest, it's certainly been discussed and proposed elsewhere for security reasons. ;D
The only thing I've seen so far is that username being tied to a Singaporean IP address when accessing IRC
Some details here.
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
I've seen it elsewhere as well including the chat log but can't find it now.
They were basically asking if ubuntu drew from debian-testing or debian-unstable. They were told testing, then left.
Of course an IP address proves nothing at all. In fact I'd only go as far as to say it almost proves they are not located in Singapore.
My gut tells me this was too long in the making for it to be just one person entirely working alone. Even if the execution of this particular stream of the attack was an individual.
I'm very dubious that this will be the only project that has been under attack.
All the more reason not to be using systemd. As from what I understand it was only changes made to ssh, for the benefit of systemd, which made xz a useful target to attack ssh.
So again, from what I understand, non systemd machines could never have been exploited using this particular attack vector (as they say :) )
So the opensshd from github which is compiled by artix not infected because the opensshd source was clean? Or is it infected but without systemd there was no threat? Or is it not infected because the makefile was on github but only used for third party alterations of the core opensshd source and we didn't use it?
Someone told me on our IRC channel that the github source was clean and we complie off it and were never affected. I looked at the github source and it seemed true, but I would like, just for accuracy, to have that confirmed for historical purposes?
Also, xz is not part of PNG?