New XZ Backdoor Scanner Detects Implants In Any Linux Binary (bleepingcomputer.com) 33
Bill Toulas reports via BleepingComputer: Firmware security firm Binarly has released a free online scanner to detect Linux executables impacted by the XZ Utils supply chain attack, tracked as CVE-2024-3094. CVE-2024-3094 is a supply chain compromise in XZ Utils, a set of data compression tools and libraries used in many major Linux distributions. Late last month, Microsoft engineer Andres Freud discovered the backdoor in the latest version of the XZ Utils package while investigating unusually slow SSH logins on Debian Sid, a rolling release of the Linux distribution.
The backdoor was introduced by a pseudonymous contributor to XZ version 5.6.0, which remained present in 5.6.1. However, only a few Linux distributions and versions following a "bleeding edge" upgrading approach were impacted, with most using an earlier, safe library version. Following the discovery of the backdoor, a detection and remediation effort was started, with CISA proposing downgrading the XZ Utils 5.4.6 Stable and hunting for and reporting any malicious activity.
Binarly says the approach taken so far in the threat mitigation efforts relies on simple checks such as byte string matching, file hash blocklisting, and YARA rules, which could lead to false positives. This approach can trigger significant alert fatigue and doesn't help detect similar backdoors on other projects. To address this problem, Binarly developed a dedicated scanner that would work for the particular library and any file carrying the same backdoor. [...] Binarly's scanner increases detection as it scans for various supply chain points beyond just the XZ Utils project, and the results are of much higher confidence. Binarly has made a free API available to accomodate bulk scans, too.
The backdoor was introduced by a pseudonymous contributor to XZ version 5.6.0, which remained present in 5.6.1. However, only a few Linux distributions and versions following a "bleeding edge" upgrading approach were impacted, with most using an earlier, safe library version. Following the discovery of the backdoor, a detection and remediation effort was started, with CISA proposing downgrading the XZ Utils 5.4.6 Stable and hunting for and reporting any malicious activity.
Binarly says the approach taken so far in the threat mitigation efforts relies on simple checks such as byte string matching, file hash blocklisting, and YARA rules, which could lead to false positives. This approach can trigger significant alert fatigue and doesn't help detect similar backdoors on other projects. To address this problem, Binarly developed a dedicated scanner that would work for the particular library and any file carrying the same backdoor. [...] Binarly's scanner increases detection as it scans for various supply chain points beyond just the XZ Utils project, and the results are of much higher confidence. Binarly has made a free API available to accomodate bulk scans, too.
Re: (Score:2)
xz is also a library that you can link (either statically or dynamically) to your own binary.
So it could affect more than just the xz binary program itself.
Re: (Score:3)
This is about the "xz" package, there is no "y". :-)
Re: (Score:1)
liblzma is the under-the-hood library for xz. And you can use liblzma in your own projects if you need a compression library (and a lot of programs do just that).
Re: (Score:2)
This is a "make test" exploit.
Have other projects been compromised with the same technique?
We don't know yet.
Re: Why? (Score:2)
Iâ(TM)m wondering what the process is with liblzma that allowed this through without a code review or a review that didnâ(TM)t understand the submission.
Sounds like marketing bullshit (Score:3, Insightful)
And it is a frigging online-scanner. The cure is worse than the disease, it seems. Also, why would the xz backdoor be in any other library?
This whole thing makes no sense, except as a means for its creators to get exposure.
Re:Sounds like marketing bullshit (Score:5, Informative)
Also, why would the xz backdoor be in any other library?
The scanner is looking for the GCC ifunc attribute from the compiler that does indirect symbol resolution at runtime. That is GCC allows multiple versions of a symbol to exist and at runtime based on attributes like CPU model/level/revision, select the proper version. That's how the XZ backdoor worked. The binary replaced the ifunc handlers for crc32_resolve and crc64_resolve, this would pop off get_cpuid which got our backdoor sub_4C90 inlined that called small bit of asm with symbol sub_4D04.
What the analysis tool is dooing is looking to see if a binary is having an ifunc attribute hooked the same way the XZ backdoor functioned.
GCC's ifunc allows interception and this exploits that to force resolution to the backdoor. Getting rid of that kind of compiler functionality is not a thing, so the thing is to see if anyone is trying to steer resolution in a finished binary. Not everything this analysis tool flags is "BAD" because ifunc is a very useful tool. But this tool allows folks to see if that is happening in places where it should not be happening.
This kind of tool is clearly NOT for the folks writing the code. This kind of tool is to ensure that we don't have another Jia Tan who sneaks something in without anyone noticing. This is a tool to ensure that a very useful function isn't abused. We have to remember that Jia Tan joined XZ utils back in 2021 and emails between the folks and Jia never indicated that Jia was intending to back stab everyone.
If Jia Tan was a state actor as some are thinking, we're going to need tools that quickly surmise any kind of abuse. Because whoever was behind all of this, they will be back.
Re: (Score:1, Troll)
So basically a false positive waiting to happen. In an online scanner. To be used by experts only because nobody else can resolve whether a positive is true or false.
Sounds very much worse than useless to me.
Re: (Score:2)
Also, why would the xz backdoor be in any other library
they explain it all in the article
Understanding the exploit ... (Score:5, Informative)
To those who are curious how this exploit works, here are some resources:
The original write up [lwn.net] by the guy who discovered the exploit.
The "Design" section in this gist [github.com] briefly describes the components of the backdoor.
And this is a detailed breakdown of how shell obfuscation [coldwind.pl] is used to hide the exploit.
There is still no detailed analysis of the binary (that I know of).
Re:Understanding the exploit ... (Score:4, Informative)
https://bsky.app/profile/filip... [bsky.app]
Some description of the binary payload.
Re: (Score:1)
To those who are curious how this exploit works
We're not. Clearly. There were three cases of the story on this exploit submitted to Slashdot. They were all in the firehose ready for publishing (and given it's Slashdot I fully expected multiple to be published). Yet we didn't cover this once. Slashdot is a place for politics and shitting on Microsoft, not for discussing code or Linux vulnerabilities it seems. :-(
Re: (Score:2)
In the analysis text allow me to quote: "openssh does not directly use liblzma. However d
So, a malware scanner for a single threat? (Score:3)
Maybe I'm looking at this too simplistically, but this sounds a lot like what traditional antivirus scanners do, but those are designed to detect many thousands of different malware varieties all at once.
What am I missing? Is there something new that this one does, besides doing *less*?
Re: (Score:2)
"AV" products as a category that are installed locally have countless different definitions and matching criteria.
This exploit is a new type of exploit. Those existing matching systems don't catch it. This is a quick one-off "test your shit here if you need to ASAP" type thing, and will then eventually be rolled into the larger, broader scanning products.
This has always been the norm with new classifications of exploits.
Re: (Score:2)
"New type of exploit."
Doesn't that describe literally every "zero-day" exploit, in the traditional sense of the phrase?
The article says that traditional AV software...
...relies on simple checks such as byte string matching, file hash blocklisting, and YARA rules, which could lead to false positives
So how does he say this new thing is different?
Binarly's detection method employs static analysis of binaries to identify tampering of transitions
Hmmm...that sounds a lot like byte string matching to me.
Re: (Score:2)
Re: (Score:2)
Sounds like a distinction only a marketing department would care about. In the end, it's just another malware, and a scanner that looks for a pattern of bytes to find it.
Re:So, a malware scanner for a single threat? (Score:4, Insightful)
You need to understand glibc ifunc. [sourceware.org] Wildly useful tool. Has the ability to be abused as is demonstrated by this backdoor.
A lot of various things were done to really hide that someone(s) was attempting to backdoor distros. This analysis purportedly looks at the means by which the backdoor is injected into the running code, which relied on GCC ifunc.
Very long story short. ifunc is a GNU extension to ELF executables that allows code to provide a resolver for symbols. The system runs the resolver and based on the return, selects an appropriate symbol to jump to. Now someone using this method alone to do evil would be caught easily. That is why the whole build script magic [coldwind.pl] and binary unit tests [tukaani.org] play a role in all of this. Now I hear you, why binary? XZ Util is a compression library. Makes sense that some of the tests to ensure things were compiled correctly is to take a known value, compress, and ensure it matches some known output binary value. And the binaries Jia Tan uploaded were very carefully crafted.
The build script allows a very carefully woven _get_cpuid to be added into the ifunc sections of a fast_crc64, fast_crc32. That allows ifunc to resolve the xz utils _get_cpuid, which NO ONE would allow if it was written out that way.
What this analysis does is observe symbol resolution and if suddenly something starts resolving to something totally different for no good reason, start throwing flags. You still need somewhat a brain to properly digest if the change in resolution is known or unknown.
Re: (Score:2)
I get the resolver thing. It still sounds like a heuristic analysis tool, which is now part of every single antimalware product.
But what the article actually says is:
Binarly's detection method employs static analysis of binaries to identify tampering of transitions
This does not sound like it's resolving symbols, it sounds more like a binary scan.
Re: (Score:2)
This one advertises Binarly's services.
What are the best open source virus scanners today? The only one I know off-hand is ClamAV, but I never found it to be very good.
Re: (Score:2)
You hit the nail on the head. It's all about marketing.
As for (noncommercial) open source virus scanners, this is a tough problem to solve using open source. The landscape of malware is so vast, and changes so frequently, that there has to be financial support to make it work. Community-supported open source software tends to evolve too slowly, because it depends on volunteers, most of whom also have a day job.
Upload binaries to a web scanner? (Score:5, Insightful)
So instead of publishing a nice script or some source code to build the scanner like sensible people have done in the past, we have to upload elf binaries?
Come on, Binarly, do the responsible thing and release the tool in source form for download.
Re: (Score:2)
Up-vote!
this should be built into package managers (Score:1)
Re: (Score:2)
Binaries compiled from the same source code won't necessarily have the same checksum, even on the same computer.
For example, a malloc() will just take control of a block of ram and whatever's in that ram when you got there is what's still there unless you take steps to zero it out.
Re: this should be built into package managers (Score:2)
I donâ(TM)t think Iâ(TM)ve seen repeated compilations of the same source produce bit identical outputs for a long time. Thereâ(TM)s normally a few bytes different every time, which I always assumed was some sort of timestamp or checksum that includes the time as one of its inputs.
Re: (Score:2)
By default, yes, but some compilers have flags to produce deterministic builds precisely for this kind of checksum validation to be useful.
Strange.. (Score:2)
I compiled a binary with gcc and uploaded it and it says: Error: Invalid file type
WTH?
Re: (Score:2)
The exploit hinged on the fact that the backdoor was in a shared library that when loaded would instruct the linker to re-route certain calls to its payload instead of the normal path. Thus I'm pretty sure it can only scan shared libraries.
Facts: BSD isn't vulnerable. System==D involved. (Score:2)