Archlinux News: The xz package has been backdoored

[securitybreach]

Quote

 

The xz package has been backdoored

2024-03-29 - David Runge

TL;DR: Upgrade your systems and container images now!

As many of you may have already read (one), the upstream release tarballs for xz in version 5.6.0 and 5.6.1 contain malicious code which adds a backdoor.

This vulnerability is tracked in the Arch Linux security tracker (two).

The xz packages prior to version 5.6.1-2 (specifically 5.6.0-1 and 5.6.1-1) contain this backdoor.

The following release artifacts contain the compromised xz:

• installation medium 2024.03.01
• virtual machine images 20240301.218094 and 20240315.221711
• container images created between and including 2024-02-24 and 2024-03-28

The affected release artifacts have been removed from our mirrors.

We strongly advise against using affected release artifacts and instead downloading what is currently available as latest version!

 

 

https://archlinux.org/news/the-xz-package-has-been-backdoored/

[securitybreach]

Arch's build of ssh doesn't link against this compromised library.

 

You can verify this with the following command but it's not immediately clear what other potential problems this compromised code does that is yet to be discovered.

 

ldd "$(command -v sshd)"

 

 

[abarbarian]

12 hours ago, securitybreach said:

Arch's build of ssh doesn't link against this compromised library.

 

You can verify this with the following command but it's not immediately clear what other potential problems this compromised code does that is yet to be discovered.

 

ldd "$(command -v sshd)"

 

 

 

My output looks like this so I am clear. I am up to date also.

 

-->sudo pacman -Q xz
xz 5.6.1-2

 

 Put brain in gear before pressing enter-->09:29:07-->Sat Mar 30-->~
-->ldd "$(command -v sshd)"
        linux-vdso.so.1 (0x00007ffe691dc000)
        libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x000071fa61210000)
        libpam.so.0 => /usr/lib/libpam.so.0 (0x000071fa611ff000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x000071fa611ab000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x000071fa610d3000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x000071fa60a00000)
        libz.so.1 => /usr/lib/libz.so.1 (0x000071fa610b9000)
        libc.so.6 => /usr/lib/libc.so.6 (0x000071fa6081e000)
        libaudit.so.1 => /usr/lib/libaudit.so.1 (0x000071fa6108a000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x000071fa6105c000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x000071fa61056000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x000071fa61048000)
        libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x000071fa61041000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x000071fa6102e000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000071fa61348000)
        libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x000071fa61026000)

 

Looks like it was a deliberate hack by one of the developers.

 

https://www.openwall.com/lists/oss-security/2024/03/29/4

 

Quote

Given the activity over several weeks, the committer is either directly
involved or there was some quite severe compromise of their
system. Unfortunately the latter looks like the less likely explanation, given
they communicated on various lists about the "fixes" mentioned above.

Quote

Particularly the latter is likely aimed at making it harder to reproduce the
issue for investigators.

Quote

Initially starting sshd outside of systemd did not show the slowdown, despite
the backdoor briefly getting invoked. This appears to be part of some
countermeasures to make analysis harder.

Quote

In xz 5.6.1 the backdoor was further obfuscated, removing
symbol names.

Quote

When called for that symbol, the backdoor changes the value of
RSA_public_decrypt@....plt to point to its own code.  It does not do this via
the audit hook mechanism, but outside of it.

Quote

For reasons I do not yet understand, it does change sym.st_value *and* the
return value of from the audit hook to a different value, which leads
_dl_audit_symbind() to do nothing - why change anything at all then?

After that the audit hook is uninstalled again.

 

So it was not just a simple typo then.

 

I wonder who the hacker was and who was paying for the hack. ? My money is on either the North Koreans or the Russians

[securitybreach]

Quote

The relevant code was pushed into:

• Debian Sid

• OpenSUSE Tumbleweed

• Arch (although, the code is designed not to execute on Arch)

• Fedora Rawhide and Fedora 40

• Homebrew

 

Out of those, only Debian Sid and Fedora Rawhide/40 are not intended to really be used day to day.

 

However, what's more concerning is what would have happened had it not been caught. If it was missed, it would have made its way into the next stable version of Debian/Ubuntu, RHEL, and SLES which are basically OSes that the internet runs on.

 

https://www.reddit.com/r/technology/comments/1brebpl/comment/kx8mow7/?utm_source=share&utm_medium=web2x&context=3

[abarbarian]

19 hours ago, securitybreach said:

However, what's more concerning is what would have happened had it not been caught.

 

Yes it is a scary thought. Just glad that there are folk out there that can keep an eye out for the bad stuff.