URGENT! XZ pkg compromized

Garuda Community
1

Wake up from a nap and whaaaaa?

https://archlinux.org/news/the-xz-package-has-been-backdoored/

This is arguably the harshest buzzkill I’ve read for awhile.

8 Likes
2

For steps to take

run in terminal

pacman -Q xz

see what version you have if affected run

sudo downgrade xz

pick one not affected

it will ask, add xz to IgnorePkg? [y/N] type y hit enter

*Personally suggestion if you have a sever with sshd or the like open the the full internet (Which you shouldn’t) a fresh reinstall of the os might be best

1 Like
3

To which version?

4

How 'bout read the announcement?

3 Likes
5

The xz packages prior to version 5.6.1-2 (specifically 5.6.0-1 and 5.6.1-1) contain this backdoor.

pacman -Q xz
xz 5.6.1-2

As I understand it, should be fine. A rolling distro FTW.

6 Likes
6
3 Likes
7

Thanks, @Colin, very educational.

In my previous post above, I have mentioned I am glad to be on a rolling distro. But then I have remembered, we get people here that did not update for 6-12 months.

1 Like
8

These people do not use ssh connections, I am sure :slight_smile:

8 Likes
9

From the EnOS forum, this seems interesting to reconstruct the history:

7 Likes
10

I use garuda-update almost everyday so I have the latest…

╭─heinrichjvr@heinrich in ~
╰─λ pacman -Q xz
xz 5.6.1-2

1 Like
11

Just to be sure: I see a lot of people saying that it should not have affected Arch from what we know so far. Is that also the case for Garuda, as it it based on Arch? Or was something changed on this distro in regards to that?

1 Like
12

No, it is correct that you don’t need to do anything except update normally.

To be clear, this backdoor is essentially theoretical for most folks. See bottom of the announcement:

Regarding sshd authentication bypass/code execution

From the upstream report (one):

openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.

Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:

ldd "$(command -v sshd)"

However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.

People who have systems that can be compromised by this backdoor have a configuration which was done in a very specific way, and are most likely aware of exactly what they need to do. Most folks do not need to worry; the right people found out about this before it became a problem that affected everyone.

Still, go ahead and take the update when you have a chance.

9 Likes
13

For good reasons. Sadly my older Snapshot did work quite flawless, but with the newest update as today, artefacts are again all over the place. Typing is horrible, etc. The downside of a rolling (awesome!) distro. Never touch a running system. :wink:

14

The combination of the new KDE Plasma 6 + Wayland + Nvidia hardware has caused some issues here - for now, using X11 and waiting for some updates should help.
People who are afraid of frequent updates can always chose an LTS distro.

1 Like
15

Restored back to the update Snapshot, as i removed all the KDE5 packages more or less by accident. But not touching the “Tweaks” and what not, what popped up after the upgrade seems it didnt broke (yet) apart.

Edit for the post below me;

Good that we are free to choose when to update and when not.

My last 2 cents. Im out.

16

agree - for those users is garuda not a fit in my opinion. If you are looking for a stable release is a rolling bleeding edge release distro not quite the answer :grin:

edit: tried to exploit it on garuda btw without success so far. Used a separat testing VM

2 Likes
17
1 Like
18

I ran the command stated in the video, this is what it says:

 ╭─heinrichjvr@heinrich in ~ 
 ╰─λ ldd "$(command -v sshd)"
	linux-vdso.so.1 (0x00007ffccbba4000)
	libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x00007a1e7d08b000)
	libpam.so.0 => /usr/lib/libpam.so.0 (0x00007a1e7d07a000)
	libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007a1e7d026000)
	libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007a1e7cf4e000)
	libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007a1e7ca00000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007a1e7cf34000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007a1e7c81c000)
	libaudit.so.1 => /usr/lib/libaudit.so.1 (0x00007a1e7c7ef000)
	libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007a1e7c7c1000)
	libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007a1e7c7bb000)
	libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007a1e7c7ad000)
	libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007a1e7c7a6000)
	libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007a1e7c793000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007a1e7d1d2000)
	libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007a1e7c78b000)

 ╭─heinrichjvr@heinrich in ~ took 8ms
 ╰─λ
19

I’ve just watched this video…

…and it tells you a simple way to tell which version of xz utils you are running.

Open the terminal and enter:

xz --version

I did, and this is what I got…

xz --version
xz (XZ Utils) 5.6.1
liblzma 5.6.1
3 Likes
20

Well actually, using xz -version you interact with a package that could be malicious (btw, update), whereas with pacman -Q xz you only talk to pacman.
I don’t want to be paranoid, just joking… :smiling_face:

1 Like