How to deal with potentially infected xz arch linux installations

darsonis · 2024-03-31 14:01:22

Hello all !

I would like to ask for some clarifications concerning the malicous releases of xz 5.6.0, 5.6.1 tarballs:
(see: https://www.openwall.com/lists/oss-secu … 4/03/29/4)

From the arch linux community the following info page was created: https://archlinux.org/news/the-xz-packa … ackdoored/

From what I read there, it is recommended to simply upgrade the system to `xz` version 5.6.1-2.

Out of caution I ask, is the system then "safe" to use if you previously had one of the affected versions installed or would you rather recommend to wipe the disk and do a complete re-install ?

And how exactly does the version "5.6.1-2" fix the malicous tarballs ?

Thx in advance !

Last edited by darsonis (2024-03-31 14:02:31)

Scimmia · 2024-03-31 14:03:11

Arch was never affected. End of story. People need to stop freaking out. The news item makes it clear that even if the payload was in the Arch package, which it turns out it wasn't, it couldn't be used.

seth · 2024-03-31 14:54:44

ewaller needs to make a new sticky for that one so people can chat-on

ignuthat · 2024-03-31 15:36:49

It depends on whether you qualify a backdoor as "malware". By itself, it does not infect your system, but it is used as part of an attack. It needs to be exploited. As the news post explains, the backdoor could not be exploited on Arch.

The git repository contained different code to the tarball the bad actor created and Arch/Gentoo/NixOS/Kali built from. The tarball contained the full backdoor, but the repository did not.

The 5.6.1-2 package uses the code directly from the repository instead of the tarball, so the latest package does not contain the backdoor. The news post doesn't explain it, but apparently the build scripts only included the backdoor on RPM/DEB systems, which Arch is not, so the packages should not have contained the backdoor anyway. I need to find a citation for this...

The bad actor has made many other changes to xz over time however, and one of those changes was to disable the landlock sandbox last month (so the 5.6.1-2 package was built with the disabled sandbox). That change AFAIK doesn't have any major security impact. There might be other backdoors in xz we don't know about but no one has found anything yet. Give it a few days/weeks for analysis to be done.

So the latest package for xz, 5.6.1-2, does not have the backdoor, and even the packages that did from late Feb to late March could not be exploited. Arch's advice is to upgrade immediately and that's all you need to do.

Scimmia · 2024-03-31 15:39:23

ignuthat wrote:

Iand one of those changes was to disable the landlock sandbox last month (so the 5.6.1-2 package was built with the disabled sandbox).

The change was in CMakeLists.txt. Arch is not using cmake to build xz, so this change did nothing at all on Arch.

ldarby · 2024-04-01 12:34:34

ignuthat wrote:

The git repository contained different code to the tarball the bad actor created and Arch/Gentoo/NixOS/Kali built from. The tarball contained the full backdoor, but the repository did not.

As explained to in this comment: https://bbs.archlinux.org/viewtopic.php … 3#p2161283, before you wrote that, that is not correct.

ldarby · 2024-04-01 13:11:20

Maybe this misunderstanding was my fault for not being clear & complete enough in this earlier comment: https://bbs.archlinux.org/viewtopic.php … 7#p2161227.

The facts are:

1) https://git.tukaani.org/?p=xz.git;a=com … 2c422d9ba7 is still present in the git repo that the arch package is built from. This is what I referred to in that comment. I don't know enough about this yet to say how severe it is, but I suspect that "disabling sandboxes" was a necessary step to get the malware to work.

2) https://git.tukaani.org/?p=xz.git;a=com … 1e274f63c0 is a separate commit that inserted the full malware (the initial version of it) into the git repo. These files containing the malware are still in the git repo that the arch package is built from. Edit to add citation about this: https://www.openwall.com/lists/oss-secu … 24/03/29/4, which the now famous initial announcement of this. It points to this commit: https://github.com/tukaani-project/xz/c … 1e274f63c0, which is in the now disabled github repo, and the same commit id is visible in the https://git.tukaani.org repo).

3) The tarballs contained the build time code to include the malware into rpm / deb builds, otherwise the malware is not included.

Last edited by ldarby (2024-04-01 13:27:42)

ldarby · 2024-04-01 13:36:33

To answer op's question, if you are confident that the known malware is the only one present in xz, then you don't need to do anything at all because it is known that this known malware wasn't included in any of Arch's packages. This was not known at the time Arch created 5.6.1-2.

If you suspect there could be other unknown malware in this software, added by the same person who added the known malware, then you should downgrade to version 5.3.1 or earlier. (personally I downgraded to 5.2.1 here: https://bbs.archlinux.org/viewtopic.php … 8#p2160998 , 5.2.10 because arch doesn't have a 5.3.1 build).

As more time passes without such other unknown malware being discovered, with more and more people world-wide picking through all the commits (and tarball contents*), then that becomes less and less likely. I think by now we can say there isn't any other uknown malware and all versions of arch's packages are safe.

Last edited by ldarby (2024-04-01 13:40:51)

Allan · 2024-04-01 13:48:25

ldarby wrote:

The facts are:
1) https://git.tukaani.org/?p=xz.git;a=com … 2c422d9ba7 is still present in the git repo that the arch package is built from. This is what I referred to in that comment. I don't know enough about this yet to say how severe it is, but I suspect that "disabling sandboxes" was a necessary step to get the malware to work.

Arch did not use CMake, so was unaffected by that commit.

ldarby · 2024-04-01 13:49:52

Allan wrote:

Arch did not use CMake, so was unaffected by that commit.

That is not relevant to my point, and is redundant to what Scimmia already said.

ignuthat · 2024-04-01 13:54:00

ldarby wrote:

Maybe this misunderstanding was my fault for not being clear & complete enough in this earlier comment: https://bbs.archlinux.org/viewtopic.php … 7#p2161227.
The facts are:
1) https://git.tukaani.org/?p=xz.git;a=com … 2c422d9ba7 is still present in the git repo that the arch package is built from. This is what I referred to in that comment. I don't know enough about this yet to say how severe it is, but I suspect that "disabling sandboxes" was a necessary step to get the malware to work.

As Scimmia explains, disabling the landlock sandbox had no impact on the Arch package as it only relates to building with CMake, which Arch does not use to build xz:

Scimmia wrote:

The change was in CMakeLists.txt. Arch is not using cmake to build xz, so this change did nothing at all on Arch.

idarby wrote:

2) https://git.tukaani.org/?p=xz.git;a=com … 1e274f63c0 is a separate commit that inserted the full malware (the initial version of it) into the git repo. These files containing the malware are still in the git repo that the arch package is built from. Edit to add citation about this: https://www.openwall.com/lists/oss-secu … 24/03/29/4, which the now famous initial announcement of this. It points to this commit: https://github.com/tukaani-project/xz/c … 1e274f63c0, which is in the now disabled github repo, and the same commit id is visible in the https://git.tukaani.org repo).
3) The tarballs contained the build time code to include the malware into rpm / deb builds, otherwise the malware is not included.

I do appreciate the correction about how much of the backdoor is present in the current sources. I...simplified it somewhat due to how 3) mitigates it.

Last edited by ignuthat (2024-04-01 13:56:08)

Arch Linux

#1 2024-03-31 14:01:22

How to deal with potentially infected xz arch linux installations

#2 2024-03-31 14:03:11

Re: How to deal with potentially infected xz arch linux installations

#3 2024-03-31 14:54:44

Re: How to deal with potentially infected xz arch linux installations

#4 2024-03-31 15:36:49

Re: How to deal with potentially infected xz arch linux installations

#5 2024-03-31 15:39:23

Re: How to deal with potentially infected xz arch linux installations

#6 2024-04-01 12:34:34

Re: How to deal with potentially infected xz arch linux installations

#7 2024-04-01 13:11:20

Re: How to deal with potentially infected xz arch linux installations

#8 2024-04-01 13:36:33

Re: How to deal with potentially infected xz arch linux installations

#9 2024-04-01 13:48:25

Re: How to deal with potentially infected xz arch linux installations

#10 2024-04-01 13:49:52

Re: How to deal with potentially infected xz arch linux installations

#11 2024-04-01 13:54:00

Re: How to deal with potentially infected xz arch linux installations

Board footer