xz compression utils backdoor found in Linux.

Started by dawlane, April 02, 2024, 06:21:05

Previous topic - Next topic

dawlane

If you don't already know by now. A backdoor was introduced into one of the main upstream repositories that every x86_64 Linux distribution relies on. It was only discovered by chance by some one working for Microsoft that noticed ssh logins were taking longer by a few milliseconds. They traced it down to the xz compression tool where the malicious code was very cleverly hidden in a test binary.

What is more surprising is how this backdoor got into the repository. It looks like author of this code actually managed to take over the upstream xz repository by social engineering, possibly by themselves or in collusion with others to get the original maintainer to give them access to do their own commits.


Derron

That backdoor must be installed by the distro or yourself (afaik only "bleeding edge" distros and eg "unstable" debian contained the "more recent" xz lib) , it also requires specific configurations to be used by certain tools (so they use i_notify and thus the xz lib, else they would by default not dynamically load the xz lib).

And of course your OS must be available over the internet. So if you use a "stupid" router and do not expose your computers ssh ports to the world I guess you are rather secure.


The author itself seems to have committed regular code too - over a lengthier time. Some blog posts over the weekend brought up funny timezone adjustments in their commits. Name of the backdoor author tries to play "Asian" (gmt+8:00) while almost all other commits werde done eastern Europe/israel/far east time (gmt+3:00 - and then it would be normal "office times" :-)).
The xz lib itself was so to say put on a single pair of shoulders - easy to give reigns to someone else (by forking and adding more things than the original code - or voluntarily).


Am excited what they find out during the next days.

bye
Ron

dawlane

#2
Quote from: Derron on April 02, 2024, 08:04:30The xz lib itself was so to say put on a single pair of shoulders - easy to give reigns to someone else (by forking and adding more things than the original code - or voluntarily).
This is one of the problems with open source software where it's either a single person, or a small team maintaining a package that becomes popular; gets to be too much work. What I find surprising is that this compromised package actually found it's way in distribution without being vetted. You would have thought that the main distribution vendors would be going over every package that gets committed with the number of vulnerabilities found over the years, especially those that a system has come to rely on. There's also been a few issues with how KDE implements themes that compromises as system.

It will be interesting to see what's discover once they've reversed engineered the code.