The xz package has been backdoored

[figueroa]

[figueroa]

[colo-des]

In reference to what is commented on:
https://bugs.gentoo.org/928134#c24
https://bugs.gentoo.org/928134#c25

I have downgrade to 5.2.5-r2, from full backups that always I do before emerge-sync
(including /usr/portage/distfiles).

[bstaletic]

[miket]

[figueroa]

How would you pull that off (lzip) with all of these dependencies to xz-utils?

[colo-des]

[miket]

[axl]

First of all, hi. Been running crazy past few days, like everyone else. But I think we have here some good news. At least something which might help.

Some managed to decode the strings from the backdoor: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01

And it seems one of them is a kill switch. https://piaille.fr/@zeno/112185928685603910

PS Also JiaTan (JiaT75) has other forks he was looking at. zstd, lz4, libarchive, squashfs-tools.

[colo-des]

The firsts tools and listings of the objects (liblzma_la-crc64-fast.o) are appearing:
https://www.openwall.com/lists/oss-security/2024/03/31/5
https://github.com/karcherm/xz-malware

For PAM's defenders, there are some gifts.

[szatox]

[flexibeast]

Although i'm very sympathetic to the critique of the design and implementation of xz, those things aren't the fundamental cause of the current situation: fundamentally, this is a social engineering attack.

Say lzip had been used in place of xz; great. It becomes widely-used, which means there's increasing pressure on Diaz to deal with bugs and feature requests. Then Diaz starts to develop health issues which make it even more difficult to deal with those bugs and feature requests. There will be an incentive for Diaz to take on extra maintainers, and a susceptibility to being brigaded into doing so, especially when a proposed maintainer seems to have been doing good work for a couple of years.

These sort of issues will continue to arise until we work out an effective way of dealing with "the xkcd 2347 problem" ("Dependency").

(i can imagine some will argue that lzip's design and implementation would have resulted in there being fewer bugs to deal with, and thus less pressure on Diaz. Perhaps; i'll leave that to the alternate-history people to analyse. But no software is bug-free - insert Knuth quote here - and past a certain threshold, any amount of bugs can be too much for a single person to wrangle.)

[colo-des]

[flexibeast]

This is OT, but a few years ago, Ted T'so wrote an interesting comment on The Orange Site about PAM on Linux, "[T]he fact that PAM was adopted by Linux is mostly my fault". Excerpt:

[szatox]

[user]

[GreenNeonWhale]

Hi,

I'm currently building a new Gentoo install. As a result of that, I did install xz-utils. I never installed the ~and64 version, thus it looks like I ducked the worst of this. However, I did install the current stable version at the time, which was one of the ones that the malicious actor signed, but not one of the currently known compromised versions. I have since downgraded to v5.4.2. I haven't run much else except for portage, and a few other things. However, it is likely that the then installed version of xz util, the one signed by the bad actor but not the known compromised version, was executed as root. My question is this: Out of an abundance of caution, should I simply wipe the entire install, and start fresh?

I'd appreciate any thoughts and/or recommendations.

Thank You!

[figueroa]

GreenNeonWhale,
Since you are still building the system, it is surely not yet multiuser and exposed to the Internet in a meaningful way. Therefore, I think wiping and starting over would be excessively paranoid.

That said, we will surely continue to learn more and hopefully systemically apply lessons learned for a safer Linux ecosystem.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[user]

[logrusx]

[colo-des]

[flexibeast]

[ritzmax72]

Is there any trace of IP or domain names in those malicious code which could reveal
the identity of the backdoor sink?

[colo-des]

You can read in the comments, the user ceretullis outlines possible IPv4 and IPV6 addresses.
https://gynvael.coldwind.pl/?id=782

[logrusx]