CVE-2024-3094
1. What is the CVE-2024-3094 ?
Recently, a vulnerability was identified in the upstream source code of a file compression format known as XZ (5.6.0 and 5.6.1). Similar to “tar” and other compression formats, it uses an efficient algorithm for compressing files named LZMA.
Such vulnerability has been assigned with the CVE-2024-3094 at a criticality of 10 out of 10. The extent of the problem is currently unclear as attempts are still ongoing to de-obfuscate the malicious files.
The NIST description for the issue has been:
Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.
2. How it all started ?
Valgrindis a set of free tools that help in debugging memory and program performance problems. The most used tool is Memcheck.
Last Friday, a backdoor was discovered in the xz-utils package commonly used for compressing software, kernel images, etc. Andres Freund a Microsoft worker identified an issue on the liblzma library as SSH logins appeared to take a lot of CPU and generate valgrind errors.
After a detailed investigation, he identified that the application injected an obfuscated script at the end of the configuration file which modified the Makefile (build process) to point to certain test files. In general, software runs through a list of tests cases to ensure its proper functioning. This was leveraged by the attacker to inject a payload.
$builddir/src/liblzma/Makefile:
1
2
3
4
5
6
am__test = bad-3-corrupt_lzma2.xz
...
am__test_dir=$(top_srcdir)/tests/files/$(am__test)
...
sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1
These test files: tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma were introduced in the following commit:
After a detailed investigations about how the exploit worked he notified Openwall about the issue. From that point, multiple developers and security researchers have been trying to understand how can this have happened.
It all started on 2021 in where a random user named JiaT75 (Jia Tan) created his account and made a Pull Request to libarchive in where he replaced secure_fprint to an unsafe variant fprintf (This attack is known as format string vulnerability). This pull request appeared to be accepted and fixed just yesterday. After this first appearance, he started to contribute to the XZ upstream brach, but at that time any changes he made had to be accepted by the owner of the project Lasse Collin.
Lasse was the only contributor to the project and had some mental health issues. He was preassured by some people (potentially Jia’s team, or Jia himself) to add Jia as a Maintainer of the project. A Maintainer of the upstream branch (main branch) is able to push code as he wished with no permission requirement from the owner. Jia was able to gain Lasse’s trust at this point so he was able to upload malicious stuff from which the test files are highlighted.
During a period of time, Lasse was off the project due to his mental health issues (he was maintaining an important project by himself and getting no retribution at all). During that time, Jia pushed multiple commits to the branch and even tried to convince multiple linux distributions to update their software stack with the vulnerable versions. He sent emails to Fedora, Debian among others. It is to say that some reported the valgrind issue and that is when Jia released the 5.6.1 version to fix those issues. The chages were accepted and the malicious version was pushed.
Unfortunately, Fedora 41 and other distributions are currently vulnerable to this issue and require downgrading to a safer version.
3. Am I affected ? What is the solution ?
To know if you are running a vulnerable version of the issue you could just check it with emerge and downgrade it if the version is 5.6.0 or 5.6.1.
1
2
3
4
5
6
7
8
9
10
11
# To check the version:
emerge --search app-arch/xz-utils
# To donwgrade:
emerge --sync
emerge --ask --oneshot =app-arch/xz-utils-5.4.2
# If on mac, running brew upgrade should fix the issue
brew upgrade xz
Do NOT run xz to check your version as that could potentially trigger the exploit.
4. Future outcomes
It is frustrating to see malicious attackers messing someone elses code to perform bad actions. The Open Source world is amazing but these people make it trumble with these sort of things. Many people work on coding solutions that are shared to everyone and is a shame seeing those people being directly targeted. Lasse and Jia got their Github account disabled but Lasse is still trying to rollback some changes that Jia did on a private git repo.
Multiple security searchers have been trying to de-obfuscate the code to find the real purpose of the exploit and appear to be taking advantage of an RSA_public_decrypt function in the sshd service to execute commands as system. This basically suggests that the vulnerability is an SSH backdoor which allow the attacker to execute remote commands (RCE). The scope of the vulnerability appeared to be focused on the amd64 linux architecture and under very specific circumstances. However, multiple systems might be affected and hence the vulnerable xz version must be removed from the systems.
From this experience we can take that we can not trust anybody that modify our codes. If someone makes any changes in our repositories we need to ensure the commits contain non-malicious code. Reviewing everything carefully, using GPT if something is unsure, etc.