Backdoor in popular Linux tool spotted by Microsoft engineer

US court orders NSO Group to share Pegasus spyware code

The xz compression tool appears to have been manipulated “for several weeks” to create a new malicious feature.

A curious Microsoft software engineer may have saved a lot of people a lot of trouble after spotting a backdoor in the xz compression tool and the liblzma5 library.

Andrés Freund shared his findings in a post on open source security site Openwall, saying he had detected what appeared to be malicious code after noticing slow performance and several strange errors on recent Debian installations.

“After seeing some strange symptoms around liblzma (part of the xz package) on Debian sid installations over the past few weeks (ssh logins are CPU intensive, valgrind errors), I discovered the answer,” said Freund.

“Upstream xz repository and xz tar files have a backdoor.”

The changes to the code appear to have been made “over several weeks,” according to Freund, and were made by a person who had been working on the project for some time, even going so far as to comment on the changes.

“Given the activity over several weeks, either the committer is either directly involved or there was some pretty serious compromise to their system,” Freund said. “Unfortunately, the latter seems the least likely explanation, given that they communicated in several lists about the ‘solutions’ mentioned above.”

The backdoor code is only present in a couple of versions of the tool and has only been added to pre-release versions of Linux distributions. Even then, the backdoor only seems to run on certain systems.

Freund shared his findings on March 29, and developers of several high-profile Linux distributions have already commented on the topic.

“Security researcher Andrés Freund informed Debian that the xz/liblzma library had a backdoor,” SUSE engineer Marcus Meissner wrote in a blog post.

“This backdoor was introduced in the GitHub xz project with version 5.6.0 in February 2024.

“Our ongoing distribution of openSUSE Tumbleweed and openSUSE MicroOS included this release between March 7 and March 28.

“SUSE Linux Enterprise and Leap are built in isolation from openSUSE. Tumbleweed code, functionality and features are not automatically introduced into SUSE Linux Enterprise and/or Leap. “It has been established that the malicious file introduced in Tumbleweed is not present in SUSE Linux Enterprise and/or Leap.”

According to Meissner, the backdoor allows “malicious actors to access systems where SSH is exposed to the Internet.”

On March 29, a Red Hat spokesperson warned customers to “stop using any rawhide Fedora cases for work or personal activities.”

Red Hat posted more tips on March 30.

“We have determined that Fedora Linux 40 beta contains two affected versions of the xz libraries: xz-libs-5.6.0-1.fc40.x86_64.rpm and xz-libs-5.6.0-2.fc40.x86_64.rpm. “At this time, Fedora 40 Linux does not appear to be affected by the actual malware exploit, but we encourage all Fedora 40 Linux beta users to revert to versions 5.4.x,” he said.

Jake Williams, a former US National Security Agency hacker, shared a simple checklist to follow to mitigate backdoor exposure.

“All organizations should take steps to remediate this vulnerability,” Williams said, “while recognizing that a threat actor is now highly unlikely to exploit it (as doing so would make attribution easier).”

Here’s what Jake suggests:

  1. Repave any Arch Linux container deployments made since February 24, 2024.
  2. Take inventory of the number of users (usually developers) on unstable Debian and Fedora branches, as these users will always be at higher risk for cutting-edge backdoors like this.
  3. Make sure teams are aware that SAST and DAST are unlikely to detect software backdoors like this, and if necessary, reevaluate your threat model in light of this.
  4. Review your firewall rules regarding SSH. Since the backdoor was designed to work with SSHD, it can only be exploited if a threat actor can connect to SSH instances running on your systems. When firewall rules are configured correctly, even organizations with vulnerable Linux instances are very unlikely to be exploited.

Leave a Reply

Your email address will not be published. Required fields are marked *