[kwlug-disc] Fw: Backdoor found in widely used Linux utility

Mikalai Birukou mb at 3nsoft.com
Sat Mar 30 10:14:32 EDT 2024


On 2024-03-30 10:00, Jason wrote:

> This is some scary stuff, and it didn't get found out by any security scanning or practices. We really dodged a bullet that one person took the time to really dig in and investigate a performance slowdown.
>
> Couple good links that have more detail:
>
> Timeline Breakdown:
> https://boehs.org/node/everything-i-know-about-the-xz-backdoor
>
> Investigation breakdown from Andres Freund (not all heroes wear capes):
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> The attackers repo JiaT75 has been disabled by GitHub, which is good and bad, because we can't really go back to see what else might have been compromised without checking mirrors.

I'd love to see what kind of pattern in a build process has been (ab)used, but repos are inaccessible.

I am looking currently at places in my build process where I patch 3rd party npm module asking how clear and transparent is it. Cause apparently, this kind of pattern has been abused.

Besides CI/CD, I wonder, could sshd be re-engineered to properly choke on bad sub-component without giving up control flow, secrets, whatever. Thoughts within ethos of "The Lazy Programmer's Guide to Secure Computing" https://www.youtube.com/watch?v=eL5o4PFuxTY

>>>> see his git repo here --
>>>> https://github.com/JiaT75
>>>>
>>>> [<https://github.com/JiaT75>](https://github.com/JiaT75)
>>>> Sheesh, a long-time trusted dev succumbing to the dark side?
>>>
>>> Not really, he(?) seems to have ingratiated himself with the beleaguered
>>> maintainer of xz, perhaps with a couple of sock puppets (people with
>>> Scandanavian and Indian(?) names).
>>>
>>> After some seemingly innocuous commits, one sock puppet pushed for a new
>>> maintainer to xz, which JiaT75 became, then another sock puppet pushed
>>> the Debian maintainers to incorporate these great new xz features into
>>> their repos. Then disappeared.
>>>
>>> This backdoor was only caught because someone happened to be testing
>>> performance on his machine, and he noticed failed ssh connections were
>>> taking too long (a mere ½ second).
>>>
>>> Some profiling indicated a lot of that time was spent in lzma, so he
>>> poked around some more and ...
>>>
>>> That guy saved the world from another HeartBleed + an OSS SolarWinds
>>> supply chain attack that would've compromised sshd on almost all Linux
>>> systems worldwide.
>>>
>>> Holy shit, we dodged a bullet there.
>>>
>>> This was an extremely crafty attack that seems to have been building
>>> over the course of a couple of years.
>>
>> Description from https://security-tracker.debian.org/tracker/CVE-2024-3094 :
>>
>> """
>>
>> 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.
>>
>> """
>>
>> ... <complex> build process extracts a prebuilt object file from a disguised test file ...
>>
>> Hiding behind complexity within CI/CD. Hence, impenetrable complexity that need to run only in one place, and is already running, is still a technical debt that should be cleared up, at least for security reason.
>>
>>> This did not require users to have xz invoked, nor even installed. The
>>> Linux kernel uses it for squashfs.
>>>
>>> Debian and Fedora at least began the process to incorporate this.
>>>
>>> The brew package manager for Macs actually did push it out, then rolled
>>> it back.
>>>
>>> Kali Linux was distributing infected ISOs for a few days.
>>>
>>> Major malware attack averted - barely.
>>>
>>> rb
>>
>> Thank you for this overview.
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
>> with the subject "unsubscribe", or email
>> kwlug-disc-owner at kwlug.org to contact a human being.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20240330/05d38937/attachment-0001.htm>


More information about the kwlug-disc mailing list