0

What are the real implications for bug CVE-2024-3094 (related to SSH and the XZ library) and how to minimize potential damage to the server?

Improve this question
1
  • 1
    Just install the fixed module. It’s already been fixed. CVE-2024-3094 was the result of malicious code, using some very specific code, to only pull in the malicious code if it meet specific requirements. So the solution is to update the module so that malicious content does not exist. This has already happened in the vast majority of those cases where the malicious code would have been included. There are online xy malicious code scanners that exist by the way
    – Ramhound
    Commented Apr 3 at 2:34

2 Answers 2

Reset to default
5

Practically, if you're running a server centric install, chances are they're not using a directly affected build. I suppose that any commit by the specific bad actor should be suspect.

There's a few things that narrow the susceptibility of your system to this exploit. As per an Ars Technica article

Any library can tamper with the inner workings of any executable it is linked against. Often, the developer of the executable will establish a link to a library that's needed for it to work properly. OpenSSH, the most popular sshd implementation, doesn’t link the liblzma library, but Debian and many other Linux distributions add a patch to link sshd to systemd, a program that loads a variety of services during the system bootup. Systemd, in turn, links to liblzma, and this allows xz Utils to exert control over sshd.

Which indicates this is somewhat narrowly tailored.

I'd also note that most of the affected distributions are bleeding edge (rawhide, debian unstable) or for specific purposes (Kali). This exploit was caught early

In theory, you can avoid this with a different SSH server or doing a build without these patches. The former is probably a better more maintainable option, but also feels like an overreaction

You can also check what version of xz you have.

As per the CVE

The critical vulnerability affects XZ versions 5.6.0 and 5.6.1.

Its trivial to check your version of XZ - I'm currently running a Ubuntu 22.04 build across most of my homelab and on these

geek@utilityboxsp:~$ xz -V
xz (XZ Utils) 5.2.5
liblzma 5.2.5

And that runs 5.2.5 which isn't affected. It is also from 2020 which I believe predates the alleged bad actor joining the project.

This is probably the case for most packages and distros you'd be running on desktop and server use. Thats a quick and easy way to verify you're not on an affected build of xz though.

Improve this answer
3

It depends on the server. While a shocking discovery, this backdoor does not affect a lot of Linux distros.

According to Ars Technica, the exploit mainly affects bleeding edge Linux distros like:

  • Fedora Rawhide
  • Fedora 41
  • Debian testing, unstable and experimental distributions versions 5.5.1alpha-0.1 to 5.6.1-1
  • openSUSE Tumbleweed
  • openSUSE MicroOS
  • Kali Linux

Thankfully this exploit was caught before it could get upstream in more major/common distros like Red Hat and Ubuntu.

In fact, Red Hat issued their own statement about this:

So if you are not using a bleeding edge distro like those listed above? Don’t worry! If somehow you are? Patch and update ASAP. Affected modules have been patched/fixed already. Patch you system and you should be all good.

PS: Feeling extra paranoid? Here is a XZ backdoor checker. Learn how to generate an ELF binary (needed for that XZ backdoor checker) from this Stack Overflow post.

Improve this answer
1
  • Here is that scanner.
    – Ramhound
    Commented Apr 3 at 2:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .