<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2024-03-30 10:00, Jason wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEnL8_cHs9kxsMG+xcvyMWx28ScBRXLQu8_ayC92t-vd3WfDnw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">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>
    </blockquote>
    <p>I'd love to see what kind of pattern in a build process has been
      (ab)used, but repos are inaccessible.</p>
    <p>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.</p>
    <p>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"
      <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=eL5o4PFuxTY">https://www.youtube.com/watch?v=eL5o4PFuxTY</a><br>
    </p>
    <blockquote type="cite"
cite="mid:CAEnL8_cHs9kxsMG+xcvyMWx28ScBRXLQu8_ayC92t-vd3WfDnw@mail.gmail.com">
      <div dir="auto">
        <div dir="auto">
          <div class="gmail_quote" dir="auto"><br>
            <blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <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" moz-do-not-send="true"
                    class="moz-txt-link-freetext">https://github.com/JiaT75</a> <a
                    href="https://github.com/JiaT75"
                    rel="noreferrer noreferrer noreferrer"
                    target="_blank" moz-do-not-send="true"><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" moz-do-not-send="true"
                    class="moz-txt-link-freetext">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"
                moz-do-not-send="true" class="moz-txt-link-freetext">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"
                moz-do-not-send="true" class="moz-txt-link-freetext">kwlug-disc-owner@kwlug.org</a>
              to contact a human being.<br>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
  </body>
</html>