Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

31–40 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#31

Post by q3k »

jchw wrote: post #27
q3k wrote: post #14

NixOS/Pkgs 23.11 unaffected, unstable contains backdoored implementations (5.6.0, 5.6.1) but their OpenSSH sshd does not seem to link against systemd/liblzma, and the backdoor doesn't get configured in (only happens on .deb/.rpm systems).

It may not have really mattered much for NixOS: > b) argv[0] needs to be /usr/sbin/sshd For once, the lack of FHS interoperability is a benefit, if only on accident.

Right, but in this case it's not even compiled it, which is arguably better than compiled in but assumed dormant :) (at least until someone actually does a full analysis of the payload).

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#32

Post by bawolff »

lpapez wrote: post #20

So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise. I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the bl…

> the entire point of that industry is to make companies pay for a security certificate so you can shift the blame onto someone else when things go wrong.

That is actually a major point of a lot of corporate security measures (shifting risk)

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#33

Post by fullstop »

agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

Also thanks to Debian for modifying openssh.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#34

Post by formerly_proven »

AdmiralAsshat wrote: post #19

> Red Hat assigned this issue CVE-2024-3094. Does that mean this affects RHEL and Fedora?

RHEL no, Fedora 41 and Rawhide yes.

https://www.redhat.com/en/blog/urgent-security-alert-fedora-...

https://lists.debian.org/debian-security-announce/2024/msg00...

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#35

Post by agwa »

delroth wrote: post #25
agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

> The systemd notification protocol could have been as simple as just writing a newline to a pipe It basically is. libsystemd links to liblzma for other features not related to notifications. (The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)

Is that protocol documented/stable? For whatever reason, daemons are choosing to link to libsystemd instead of implementing it themselves.

It doesn't matter that libsystemd links to liblzma for other reasons. It's still in the address space of any daemon that is using libsystemd for the notification protocol.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#36

Post by Jasper_ »

agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

That is all the protocol is. From https://www.freedesktop.org/software/systemd/man/latest/sd_n...:

> These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable.

The simplest implementation (pseudocode, no error handling, not guaranteed to compile), is something like:

    const char *addrstr = getenv("NOTIFY_SOCKET");
    if (addrstr) {
        int fd = socket(AF_UNIX, SOCK_DGRAM, 0);
        struct sockaddr_un addr = { .sun_family = AF_UNIX };
        strncpy(addr.sun_path, sizeof(addr.sun_path), addrstr);
        connect(fd, (struct sockaddr*) &addr);
        write(fd, "READY=1");
        close(fd);
    }

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#37

Post by woodruffw »

0x0 wrote: post #9

Homebrew is currently shipping 5.6.1 (and was shipping 5.6.0 as well). Hopefully not affected on mac?

Homebrew reverted to 5.4.6 once the maintainers became aware. The current understanding is that macOS is not affected, but that's not certain.

[1]: https://github.com/Homebrew/homebrew-core/pull/167512

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#39

Post by keepamovin »

lpapez wrote: post #20

So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise. I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the bl…

If you installed xz on macOS using brew, then you have

  xz (XZ Utils) 5.6.1
  liblzma 5.6.1
which are within the release target for the vuln. As elsewhere in these comments, people say macOS effect is uncertain. If concerned you can revert to 5.4.6 with

  brew upgrade xz

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#40

Post by tutfbhuf »

fourfour3 wrote: post #21

Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.

I upgraded Arch Linux on my server a few hours ago. Arch Linux does not fetch one of the compromised tarballs but builds from source and sshd does not link against liblzma on Arch.

  [root@archlinux ~]# pacman -Qi xz | head -n2  
  Name            : xz  
  Version         : 5.6.1-2  
  [root@archlinux ~]# pacman -Qi openssh | head -n2
  Name            : openssh
  Version         : 9.7p1-1
  [root@archlinux ~]# ldd $(which sshd) | grep liblzma
  [root@archlinux ~]#
It seems that Arch Linux is not affected.
Post reply on HN