Crisis averted: A recap of the OpenSSH and XZ/liblzma incident

A novel backdoor (CVE-2024-3094)  was recently discovered from a widely used xz-utils 'liblzma' data compression library build system. This backdoor reportedly targets the OpenSSH server but has the potential to target any application that integrates with 'systemd', uses 'OpenSSL', and can be contacted from the network. Pending detailed analysis of the malicious binary code injected, the full scope and impact of the backdoor are still unknown.

Contents

Tectia SSH Client/Server by SSH Communications Security is not affected by XZ/liblzma
How does the backdoor work?
How was the liblzma backdoor injected into the library?
How dangerous is the liblzma?
How was liblzma discovered? 
Open source is free but comes with a cost

Tectia SSH Client/Server by SSH Communications Security is not affected by XZ/liblzma 

We at SSH Communications Security want to emphasize that our remote server and application access product Tectia SSH Client/Server is not affected by the liblzma vulnerability. As cybersecurity experts, we keep a keen eye on risk mitigation, and we've been consciously avoiding dependencies on external libraries. The few validated dependencies are distributed as part of the installation package.

How does the backdoor work?

The XZ/liblzma backdoor stays in a dormant state until activated. It works and spreads like this: 

Linux 'systemd' super-service application library 'libsystemd' depends on the malicious 'liblzma' library. Many Linux server applications use 'libsystemd' allowing 'systemd' to monitor and control execution. This creates an indirect dependency between the application and 'liblzma'. 

Backdoored 'liblzma' contained an initialization routine that allowed it to inject back-door into the server application at the time when it is started and loaded into memory. 

The backdoor was distributed in files disguised as test vectors of 'liblzma' and changes on 'autoconf' script used during the build process. These packaged sources are used for the build process of most Linux distributions. 

How was the liblzma backdoor injected into the library?

The harsh fact is that one of the maintainers of the library injected the malicious code into it. CVE-2024-3094 is a vulnerability discovered in the open-source library XZ Utils that stems from malicious code that was pushed into the library by one of its maintainers.

Almost two years ago, the adversary started contributing to the XZ project. Over time, the malicious actor built trust and credibility for the project and started getting wider permissions for the repository. It wasn’t long until they were given maintainer responsibilities which eventually culminated in release-manager rights.

How dangerous is the liblzma? 

Ubuntu 24.04LTS was a month away from being shipped with this backdoor, with other distros being on the same boat. Maybe the best way to describe it is this: had it gone undetected, Linux servers would have been running with a bomb waiting to be activated remotely. CVE-2024-3094 is a digital sleeper agent waiting for someone out there to pull the trigger when the time is right, potentially causing one of the most devastating acts of cyberterrorism ever. 

How was liblzma discovered? 

Luckily this backdoor was discovered in an early stage, and most of the Linux user community stays safe. A lot of credit goes to Andres Freund from Microsoft who was determined to figure out why things had slowed down on the PostgreSQL test lab and discovered the liblzma backdoor.

Thank you, Andres, for your efforts! You deserve worldwide recognition for preventing what could have been a global catastrophe.

Open source is free but comes with a cost

About dangers of voluntarily maintained projects that end up as parts of large ecosystems: The users of open-source software (OSS) projects enjoy the benefit of the original author's work, who rarely gets proper compensation or even help. Often there's a considerable support load towards the maintainers, finally exhausting them.

Bad actors volunteer to help maintainers - maybe using social pressure as their tool - and in exchange, they gain a foothold on the project, on the back of the reputation of the original author and the existing installation base. The rest is history.

Read more about the actual costs of open-source software in this comparison sheet >>>

This is why we at SSH recommend that businesses use tested and validated professional products and experts when building critical networks, infrastructures, and data transfers. Open-source software is a great initiative and an integral part of a modern, functioning digital infrastructure but should organizations outsource their critical security needs to a community? We think not.