XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access

[avis]

Debian wants to go even further:

Debian is currently looking into downgrading it even further, before the first contribution from the known bad actor, which may be an older 5.2 release (later ones were also cut by them), then reapplying only the security fixes that came later on top manually, for now.

Yes I know. I don't like this kind of software at all. Especially scripts that download stuff and immediately run it look suspicious as hell. Libraries should be isolated much more. Instead of binary linking, something like xz should be a source/sink for pipes, nothing more. If you need directory listing, there should be an isolated API.

Android has been striving to work just like that.

[wooptoo]

It's the *source* tarball which contains the final piece of the malicious code, not the binaries. It's no coincidence that starting from today Arch Linux switched to the git tag lol

Actually an Arch Linux maintainer noticed the discrepancy between the git source code and the distributed tarballs, and introduced this change a day before this exploit was publicly announced.

The reason for this was because Arch Linux is currently working on making all packages reproducible, which lets users verify the distributed packages from Arch Linux.

This is precisely the sort of issue reproducible builds can prevent: https://reproducible-builds.org

edit: https://reproducible.archlinux.org

[Monsterovich]

in case the malicious M4 macro is present.

When will people finally realize that autotools is a relic of the past that should finally die. If it was cmake, it's highly likely that no backdoor would have been hidden. It's long past time to recognize autotools as a trouble spot.

[Paradigm Shifter]

From what I've understood, this shows a pathologically careful approach to get this to the point where it can do what we currently know it can, although it may turn out other programs are affected too in other ways...

- malicious code is in test files for xz, compressed as xz files
- because systemd pulls in liblzma, systemd is vulnerable (this is where the next revelation around this will probably come from)
- if ssh is built with systemd support, ssh becomes vulnerable

Please correct me if I'm wrong, but non-systemd distributions will therefore not have the ssh vulnerability (although they may still have the xz vulnerability if the affected versions are installed)?

edit: Also seems like libselinux pulls it in too?

[Paradigm Shifter]

Debian wants to go even further:

GitHub has killed that repo, so comments can't be read.

[piotrj3]

I will ask again - why linux is not using original project made by Igor Petrov (aka LZMA sdk or p7zip). We have instead weird fork made by untrusted people that even use outdated and less efficient version of LZMA/LZMA2 algorithm.

[Monsterovich]

I will ask again - why linux is not using original project made by Igor Petrov (aka LZMA sdk or p7zip). We have instead weird fork made by untrusted people that even use outdated and less efficient version of LZMA/LZMA2 algorithm.

Is it commercial?

[Blademasterz]

GitHub has killed that repo, so comments can't be read.

https://web.archive.org/web/20240330000954/https://github.com/tukaani-project/xz/issues/92

[Sonadow]

That's the right way to do it but many projects have external build-time dependencies which are often downloaded via the Internet.

And then, imagine whatever you're trying to build already contains malware (at source level). OK, you've now compiled malware which will activate as soon as it's used/launched.

Building in an isolated environment with no Internet is not a panacea unfortunately.

This is already not possible when building Python packages or Rust binaries. pip3 will pull dependencies from the internet to satisfy build requirements as will cargo for rust binaries.

[Paradigm Shifter]

https://web.archive.org/web/20240330...t/xz/issues/92

Cheers!

...

Seems like one of the steps to preventing this happening again is the rule: no binary files in your source repo.