<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite"
cite="mid:c6e0b686-f351-4674-bbfc-157bb4baa3e6@ronaldbarnes.ca">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">see his git repo here --
<a class="moz-txt-link-freetext" href="https://github.com/JiaT75">https://github.com/JiaT75</a> <a class="moz-txt-link-rfc2396E" href="https://github.com/JiaT75"><https://github.com/JiaT75></a>
Sheesh, a long-time trusted dev succumbing to the dark side?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>Description from
<a class="moz-txt-link-freetext" href="https://security-tracker.debian.org/tracker/CVE-2024-3094">https://security-tracker.debian.org/tracker/CVE-2024-3094</a> :</p>
<p>"""</p>
<p>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.</p>
<p>"""<br>
</p>
<p>... <complex> build process extracts a prebuilt object file
from a disguised test file ... <br>
</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:c6e0b686-f351-4674-bbfc-157bb4baa3e6@ronaldbarnes.ca">
<pre class="moz-quote-pre" wrap="">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</pre>
</blockquote>
<p>Thank you for this overview.<br>
</p>
</body>
</html>