5 questions about the malware in compression tool xz: was this a backdoor? – Computer – News

Researchers have found a striking bug in compression tool xz. This could potentially cause a lot of damage in many Linux distros. The news came out just before the weekend and much is still unknown, but a picture is starting to emerge of a deliberate back door. What do we know now about the bug in xz?

What is xz?

Xz is a compression tool. The software allows lossless compression and is mainly found on Linux. The tool is popular: xz, and specifically the xz-utils program, is included by default in Ubuntu, Debian, Fedora, Kali Linux and openSUSE, among others, but practically in most Linux distros.

The source code of xz was open source until recently, but on Sunday it made it to GitHub offline repo. This makes it more difficult to find information about the tool online, although there are now plenty of forks available. The developers also have there is still a mirror online.

Users on a Linux system can use the command xz --version see which version they are running.

What happened?

On Friday afternoon the news spread that there seemed to be a bug in xz. Tweakers wrote there on Friday evening this article about. The news came out through Andres Freund sent a message to the oss-security mailing list. Freund is a PostgresSQL developer at Microsoft and was astute enough to notice the bug. He describes how he saw a noticeable latency of around 500 milliseconds when connecting via SSD. “I did some microbenchmarks to optimize the system and noticed that SSD processes were causing surprisingly high CPU usage,” he writes.

Soon after, the makers of several Linux distros started sending out warnings to users. Among other things Debian, openSUSE in Fedora-maker Red Hat warned about the bug.

The vulnerable version of xz-utils ultimately appeared to be in only a handful of distros, as most distros had not yet updated xz. The warnings turned out to be a bit premature, but nevertheless the distros have taken measures to roll back xz-utils to an earlier version.

Who or what is vulnerable?

Because Freund spotted the vulnerability early on, the damage was relatively limited. Versions 5.6.0 and 5.6.1 of xz-utils appear to be vulnerable, but they had not yet made it into the upstream of the package. That is why there were no major Linux distros where the vulnerable versions have been included in a stable release.

However, some early releases, such as public betas, are vulnerable. These are mainly Fedora Rawhide and Debian testing. Also package manager Homebrew for macOS contained the vulnerable version 5.6.1 from xz-utils. Meanwhile, all those distros, and Homebrew, have rolled back xz-utils to version 5.4.6.

In any case, the vulnerability is only in the xz-utils installation package. The Git repo is not affected.

Xz also creates the library liblzma On. Software that contains that library can also be vulnerable.

What exactly is the vulnerability and what could a possible attacker do with it?

For starters, the full extent of the bug is not yet fully known. Researchers are currently still busy developing the tool reverse engineerso there will probably be more developments in the coming days or weeks.

In any case, what is already clear is that the update is called an installation script build-to-host.m4 turned. That managed to place itself in positions that by sshd were used, a file that is required on Linux systems to make SSH connections. This is done via glibc – so systems are only vulnerable if they have that library installed, but that is almost always the case. The malware then uses glibc mechanism Ifunc to bypass the authentication protocol in OpenSSH.

Some researchers see the bug as a remote code execution vulnerability
There are several technical write-ups of the malware that go into more depth than we can do here. For a detailed description you can Filippo Valsorda’s analysis read, which explains why he thinks the bug is not just an authentication bypass but a remote code execution. Furthermore, Sam has James written a good explanation which also states under what conditions the malware works. Security researcher Gynvael Coldwind also has wrote an extensive analysis of how an infection with xz-utils works.

Who is behind the malware? And is this a backdoor, or just a bug?

In recent days, researchers have delved deeper into perhaps not the most important, but certainly the most interesting question surrounding the bug: how could this happen? It is now clear that xz-utils may be used by millions of computers, but is only maintained by two people. It is somewhat reminiscent of that the vulnerability in Java library log4jwhich was included in virtually all software but was maintained by only one person.

With xz-utils it seems again the problem described by XKCD to look around the corner, although the situation seems to be somewhat different. In this comprehensive analysis by evan boehs is the history of xz-utils read back, and specifically from one of the two maintainers. Xz-utils was maintained by Jia Tan, who goes by JiaT75, and by Lasse Colin, who goes by Larhzu. Larhzu has management of the xz website and writes briefly about the situation, in which he seems to distance himself from Jia Tan. “Xz-utils 5.6.0 and 5.6.1 included a backdoor. These tarballs were created and signed by Jia Tan,” he writes. Evan Boehs writes that Jia Tan created his GitHub account in 2021 and was the first commit to make a push request to the tool libarchive, which can be found in his profile.

Jia Tan was born in June 2022 a maintainer of xz-utils, together with Lasse Colin. They were the only people who maintained the tool over the past two years. Since then, Jia Tan has made several changes to xz-utils that now appear to have potentially made the system unsafe. On February 23 in 9th of March Jia Tan made two more adjustments that would ultimately lead to the back door.

Although, back door? Can we say that so definitively? A back door implies a conscious action. It could theoretically be possible that someone was making commits to xz-utils under Jia Tan’s name. But recent actions by the developer make that unlikely. So says a developer of Fedora that Jia Tan spent weeks in discussions with him and other Fedora developers to get the tool into the OS ‘because of the great new features’. Moreover, it seems unlikely that Jia Tan honestly thought the adjustments were improvements; The malware is far too detailed for that. Furthermore, the malware engaged in heavy obfuscation, so someone, probably Jia Tan, eventually tried to keep the malware quiet.

For what purpose this happened and whether Jia Tan worked as a state hacker, for example, is still far from known. There is a lot of speculation about this, but it is still too early to say anything about it. Researchers are still studying the malware; expect more information about this in the coming weeks.