Re: Malware find in the news: xz related.

Grant Taylor <gtaylor@tnetconsulting.net> wrote:

On 3/31/24 08:38, John McCue wrote:

Thanks, here is another interesting link that describes how the issue
occurred and indicates why *BSD and Distros like Slackware would not
be vulnerable.

 
My understanding is that effectively the differentiating factor of if
a distro is impacted or not is if it uses systemd or not.

Yes, this seems to have been part of the "connection".

Purportedly sshd itself doesn't use xz.

It does not.  Directly that is.

But sshd built on / for systemd distros end up having xz added as a
library / dependency because of systemd compatibility because systemd
does use xz for things.

Some distros, in their zeal to "systemd all the things" patch OpenSSH
to link it to a systemd library for logging purposes.  That addition of
a systemd library for logging is what ultimately linked the xz/lzma
library into OpenSSH because somewhere in that systemd libraries
dependency chain was libxz/lzma.

As such, my supposition is that, things like *BSD, Slackware, and
Gentoo (OpenRC old default) aren't affected because they don't have
-> use systemd.

They are not, because their OpenSSH is not linked to libxz/lzma in any
way.

But....  this is nearly a "Reflections on Trusting Trust" [1] level
opsec.  attempt, and so just because BSD/Slackware/Gentoo happen to be
immune this time, does not mean they would be immune to another opsec. 
attempt against an OpenSSH direct dependency which might gain a
similarly well hidden backdoor.

On my Slack 15.0 system, sshd directly links to the following
libraries:

$ ldd /usr/sbin/sshd
    linux-vdso.so.1 (0x00007ffee1ab9000)
    libnsl.so.2 => /lib64/libnsl.so.2 (0x00007fdb09586000)
    libpam.so.0 => /lib64/libpam.so.0 (0x00007fdb09575000)
    libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fdb09290000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fdb0928b000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007fdb09286000)
    libz.so.1 => /lib64/libz.so.1 (0x00007fdb0926c000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fdb09230000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdb09216000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fdb091c4000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fdb090ed000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fdb090bf000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fdb090b9000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fdb08ed8000)
    libtirpc.so.3 => /lib64/libtirpc.so.3 (0x00007fdb08ea8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fdb096cf000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdb08e87000)
    libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fdb08e78000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fdb08e71000)

A similar backdoor in any one of these would open up sshd for remote
access, even though I have no systemd anywhere on my system.

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf