Impact of jiatan SSH malicious code backdoor from xz utils. Is Arch template or any of Qubes templates affected?

User Support
1

I’ve always been terrified of Arch and never knew why.

So by now everyone knows that malicious code designed to break ssh has gotten into some bleeding-edge distros and unstable repositories but didn’t get into any of the Debian stable or Fedora stable templates on Qubes.

Did it impact Arch and if this is confined to an Arch template could it have affected any other part of Qubes? It shouldn’t? Did this get into kali-core template?

For reference:

https://lists.debian.org/debian-security-announce/2024/msg00057.html

2

@solene Wanna cross-post from the All around qubes topic?

3

For Qubes OS users, dom0 is unaffected, fedora and debian templates aren’t affected either.

Kali is affected, Archlinux isn’t affected, Gentoo is unaffected.

I also published a small blog post about this because this supply chain attack made me rethink some infrastructure strategy: Solene'% : Lessons learned with XZ vulnerability

2 Likes
4

Should I just delete my kali-core template?

I did create a VM based on this template but I don’t know if I’ve used it for running anything.

Good thing I was running kali in qubes? The Kali VM may have been run with access to sys-whonix.

5

When I say “affected” or not, it’s only if sshd is being linked by the xz version that is compromised.

We currently don’t know if the vulnerability touch other component.

As said just above, fedora and debian templates never used that compromised version.

1 Like
6

I don’t know what sshd but have used ssh.

For non-experts who use Qubes because it’s cool and exciting, but aren’t that knowledgeable, does it make sense to delete kali-core templates and things based on that until more of this is looked at by experts?

7

sshd is the ssh server, so, at the moment, we only think that systems running sshd with the compromised xz version were affected.

It’s safe to think that any system that has been running the xz version is compromised until we know more. On Qubes OS, you could stop using kali based qubes until this get sorted out. Changing the template of an kali AppVM may not be enough if some payload has been added to the user directory, I think it’s paranoid to think it happened but we still don’t really know consequences.

It’s a very complicated exploit, security researchers are trying to figure the scope, IT professionals like me don’t have much more information at the moment :confused:

1 Like
8

I don’t think I tried to use kali-core with anything other than one VM and mainly because there’s very little pre-installed in kali-core.

From what I understand of qubes, if I delete kali-core and the VM, I do not need to reinstall a sys-whonix VM or reinstall a whonix template? The isolation protects me?

9

yes, isolation protected you here, only qubes running with kali template were “contaminated”.

However, kali isn’t affected if it wasn’t updated before 26th march :slight_smile: !

10

so kali-core is fine

what about arch? i installed that before i figured out how to just get nvidia drivers installed in debian

i thought it did get into arch. are you sure it’s okay? you’re probably right? i read somewhere it got in.

also how do i check my debian repositories inside the template i created for installing the nvidia drivers? i don’t think i added sid but i was trying to get newer drivers so anything is possible

11

in the link I posted above: Arch Linux - News: The xz package has been backdoored

12

dpkg -l | grep xz I guess

13

so delete arch-templates and VMs attached to it?

or run the templates and check the version using dpkg?

i think i’ll just delete the arch templates and reinstall them later?

14
2 Likes