oss-sec mailing list archives
Re: backdoor in upstream xz/liblzma leading to ssh server compromise
From: "Rein Fernhout (Levitating)" <me () levitati ng>
Date: Sat, 30 Mar 2024 01:08:22 +0100
Andres, maybe you (or Florian or someone else) can post the .o file from5.61 as well (gzipped just like the previous one, please)?
I think the attached liblzma_la-crc64-fast.o is taken from 5.6.1. I compiled 5.6.1 and ended up with a nearly identical object file.When I compiled 5.6.0 I got a larger object file with additional symbols crc64_generic, crc64_arch_optimized and crc64_resolve.
Attached is that object file. On 2024-03-29 22:46, Solar Designer wrote:
On Fri, Mar 29, 2024 at 12:19:26PM -0700, Andres Freund wrote:On 2024-03-29 19:44:05 +0100, Matthias Weckbecker wrote: > I've attached a yara rule to detect the *.o droplet you attached in the > email (liblzma_la-crc64-fast.o.gz). Unfortunately xz 5.61 added further obfuscations, making it harder todetect. Should have made it clearer that the attached .o was from 5.60. Among others 5.61 removed the two symbols you're checking against here. That's why Vegard's script looks for a specific instructions sequence, but obviously isalso more obscure :/Andres, maybe you (or Florian or someone else) can post the .o file from5.61 as well (gzipped just like the previous one, please)? On Fri, Mar 29, 2024 at 08:51:26AM -0700, Andres Freund wrote:openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemddoes depend on lzma.It is indeed a security risk that sshd on major distros brings in so many libraries. For example, on RHEL 9.x and its rebuilds, "ldd sshd"is 28 lines. In the Rocky Linux SIG/Security override package, we've sofar reduced this to 13 lines, which is still a lot: https://sig-security.rocky.page/packages/openssh For systemd notification, I patched it (half a year ago, so not in response to these new findings) to dlopen() libsystemd into a new sshdchild process that's briefly spawned on sshd service startup or restart,notifies systemd, and exits. I could probably also drop privileges in that child process, but so far I didn't bother. I just didn't want those libraries to stay in the process address space after startup. Luckily, RHEL is not affected by the xz backdoor anyway, but if it were I think these changes would just happen to have prevented the backdoor from working. Indeed, it's still bad code that could run as root (and even if not in sshd, then in other services that use libsystemd), so it could have as well e.g. modified sshd on disk, but its current way of dynamically plugging into sshd authentication wouldn't work. I've attached the patch, which applies on top of Red Hat's patches. Ifusing it in a package, explicit dependency on libsystemd (or the packagethat provides it) should be added to the (sub)package with sshd, e.g.: Requires: systemd-libs That's because the package manager would no longer automatically detect the dependency, which is now a soft one. I took this approach back then in order not to drop functionality, but I'd re-think it now. Perhaps systemd notification isn't worth even thereduced risk, and should be dropped completely. For the latter, an editto the systemd unit file is needed, changing "Type=notify" to "Type=simple", which should fit "sshd -D". Not only Red Hat'ish distros, but also Debian and Ubuntu are similar in this respect, and I think should want to make similar changes. Alexander
Attachment:
liblzma_la-crc64_fast.o
Description:
Current thread:
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise, (continued)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise terraminator (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Rein Fernhout (Levitating) (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Matthias Weckbecker (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Andres Freund (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Loganaden Velvindron (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Demi Marie Obenour (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Mar 31)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Michael Tokarev (Mar 31)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Andres Freund (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Rein Fernhout (Levitating) (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Andres Freund (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Rein Fernhout (Levitating) (Mar 30)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Matthias Weckbecker (Mar 30)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Andres Freund (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Andres Freund (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Liguori, Anthony (Mar 29)