Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: xz/liblzma is compromised upstream (backdoor) (Read 2107 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: xz/liblzma is compromised upstream (backdoor)

Reply #15
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.
[...]

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

 

Re: xz/liblzma is compromised upstream (backdoor)

Reply #16
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?

Re: xz/liblzma is compromised upstream (backdoor)

Reply #17
Does this mean Artix was completely unaffected or did the old PKGBUILD somehow get built?

"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/

Re: xz/liblzma is compromised upstream (backdoor)

Reply #18
Does this mean Artix was completely unaffected or did the old PKGBUILD somehow get built?

"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:
Code: [Select]
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

Re: xz/liblzma is compromised upstream (backdoor)

Reply #19
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

Re: xz/liblzma is compromised upstream (backdoor)

Reply #20
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.

Re: xz/liblzma is compromised upstream (backdoor)

Reply #21
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

Re: xz/liblzma is compromised upstream (backdoor)

Reply #22
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

Re: xz/liblzma is compromised upstream (backdoor)

Reply #23
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.
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 :) )


Re: xz/liblzma is compromised upstream (backdoor)

Reply #25
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?