Backdoor in SSH Server Caused by XZ/LZMA Compression Library – Update Immediately!

Update on 3 April 2024 (in blue and italics): added vulnerable Linux distributions, more specific malicious library behaviour, recommendations.

A software developer discovered a backdoor in the lzma library, which is used for compression and is part of the xz-utils package. This library is used worldwide in software for archiving, multimedia handling and may be found in a number of third-party software. Specifically, this code is executed in the ssh login process on major Linux distributions.

Malicious code is present in versions 5.6.0 and 5.6.1 and was added to the library’s source code in the afternoon of 23 February 2024.

Malicious code is present in the source code of the library itself, but fortunately it is not always active. It is compiled into a functional version of the library only after a series of conditions are met: a Linux operating system on x86_64 architecture (64-bit Intel), if the gcc compiler and gnu linker are used, only as part of creating a DEB or RPM package. The malicious part is specifically adapted to the situation where the LZMA library is included in the OpenSSH process. Once activated, it performs a series of steps that culminate in adding malicious functionality to the RSA_public_decrypt function, which is likely to allow an attacker to log into the affected system, allowing the attacker to execute arbitrary commands without logging in and without knowledge of the login name and password. The commands are sent in encrypted form, so the network detection is not possible.

The vulnerability has been assigned the identifier CVE-2024-3094 and achieves the highest possible CVSS score of 10.0 (full system compromise).

Affected versions

Since these are very new versions of the libraries, mainly new versions of applications, “unstable”, “testing” or “bleeding edge” Linux OS distributions and those servers that are updated from the source code, are affected. In the case of Linux distributions, these include, for example

  • Fedora 40 beta,
  • Fedora 41,
  • Fedora Rawhide,
  • Debian unstable (SID),
  • OpenSUSE Tumbleweed,
  • OpenSUSE MicroOS,
  • Kali Linux,
  • Arch Linux VM and containers.

On the other hand, stable, LTS versions of distributions are mostly not affected.

Recommendations

  • Update all affected systems as soon as possible. This applies in particular to the Linux operating system. However, to be safe, also update the homebrew packages on macOS if you use this package system, though, there is currently no indication that these libraries have also been compromised. It is confirmed that packages on processor architectures other than x86_64 and on operating systems other than GNU/Linux do not contain malicious code, however, it is recommended to update them to minimize the risk of flaws in vulnerability detection.
  • If the operating system does not offer an update that fixes this problem, install an older version of the package, 5.4.6. This version should not be affected.
  • To verify the installed versions, check the xz-utils, liblzma, liblzma5 packages. Check if they are in vulnerable version 5.6.0 or 5.6.1. Be aware that some distributions do their own package version numbering (e.g. Debian testing refers to the patched version as “5.6.1+really5.4.5-1”). In order to find out the version, you can also use the xz -version
  • If you are the developer of an application or product that uses the XZ library and you have released an application with a vulnerable version, release a new version with the library version downgraded to 5.4.6.
  • The vulnerable library version can also be verified with a script that can be downloaded at https://www.openwall.com/lists/oss-security/2024/03/29/4/3. Note that the script may not affect all versions containing malicious code.
  • If it is possible to recompile SSH, you can apply a simple patch available at https://github.com/amlweems/xzbot/blob/main/openssh.patch that will log received commands in the format used by the attacker.
  • If you found a vulnerable version of the library and at the same time your SSH was accessible from the public Internet, we recommend that you consider the device compromised. In response to the incident, we recommend the following steps
  • obtain a memory and disk image of the server for forensic examination;
  • reinstall the device from scratch;
  • consider all data, passwords, encryption keys present on the device to be compromised. Have the TLS certificates revoked and issue new ones;
  • also contact the National Cyber Security Centre at [email protected].

Sources


« Späť na zoznam