<div dir="auto"><div>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.<div dir="auto"><br></div><div dir="auto">Couple good links that have more detail:</div><div dir="auto"><br></div><div dir="auto">Timeline Breakdown:</div><div dir="auto"><a href="https://boehs.org/node/everything-i-know-about-the-xz-backdoor" rel="noreferrer noreferrer" target="_blank">https://boehs.org/node/everything-i-know-about-the-xz-backdoor</a><br></div><div dir="auto"><br></div><div dir="auto">Investigation breakdown from <span style="color:rgb(0,0,0)">Andres Freund (not all heroes wear capes):</span></div><div dir="auto"><a href="https://www.openwall.com/lists/oss-security/2024/03/29/4" target="_blank" rel="noreferrer">https://www.openwall.com/lists/oss-security/2024/03/29/4</a><br></div><div dir="auto"><br></div>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.</div><div dir="auto"><br></div><div dir="auto">Jason<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Mar 30, 2024, 9:53 a.m. Mikalai Birukou <<a href="mailto:mb@3nsoft.com" rel="noreferrer noreferrer" target="_blank">mb@3nsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
  
  <div>
    <span style="white-space:pre-wrap">
</span>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre>see his git repo here --
<a href="https://github.com/JiaT75" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/JiaT75</a> <a href="https://github.com/JiaT75" rel="noreferrer noreferrer noreferrer" target="_blank"><https://github.com/JiaT75></a>

Sheesh, a long-time trusted dev succumbing to the dark side?
</pre>
      </blockquote>
      <pre>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 href="https://security-tracker.debian.org/tracker/CVE-2024-3094" rel="noreferrer noreferrer noreferrer" target="_blank">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">
      <pre>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>
  </div>

_______________________________________________<br>
kwlug-disc mailing list<br>
To unsubscribe, send an email to <a href="mailto:kwlug-disc-leave@kwlug.org" rel="noreferrer noreferrer noreferrer" target="_blank">kwlug-disc-leave@kwlug.org</a><br>
with the subject "unsubscribe", or email<br>
<a href="mailto:kwlug-disc-owner@kwlug.org" rel="noreferrer noreferrer noreferrer" target="_blank">kwlug-disc-owner@kwlug.org</a> to contact a human being.<br>
</blockquote></div>
</div></div>