liblzma CVE-2024-3094

uther · 2024-03-29 22:44:56

Subject: backdoor in upstream xz/liblzma leading to ssh server compromise:

https://www.openwall.com/lists/oss-secu … 24/03/29/4

I wanted to check if Devuan is vulnerable to this so I've checked with `ldd /usr/sbin/sshd` and it looks that in Devuan liblzma is not a shared library for sshd.

stopAI · 2024-03-30 12:20:13

Excalibur and Ceres are affected. Daedalus and older is not affected.

P.S.
Updating is safe but we don't know what the obfuscated backdoor code did. It might persist even after you upgrade the package itself.

Last edited by stopAI (2024-03-30 12:25:06)

uther · 2024-03-30 16:04:30

Excalibur and Ceres are affected.

I guess there are levels of granularity to this. Does libelogind use notifyd underneath? Or in more layman terms are Excalibur/Ceres vulnerable to the same extent as Debian sid?
I rolled back from Ceres to Daedalus (with Timeshift) on one of my machines. I'm not sure if this is enough, I'll monitor firewall logs to see if there is any suspicious traffic.
I use this machine mainly for testing new GPU-related packages, and unfortunately I used it for the past week.

jue-gen · 2024-03-31 08:27:49

Take a look at this:

https://toot.community/@devuan/112185687582188156

uther · 2024-03-31 13:12:55

Thanks. That's a little more reassuring.
I saw in other thread being mentioned that Ceres and Excalibur are affected and I want to know to what extent.
I believe this guy is wrong as libsystemd0 is not installed in Devuan - at least in Daedalus: https://gist.github.com/thesamesam/2239 … nt-5007060

steve_v · 2024-03-31 14:51:34

libsystemd0 is not installed in Devuan - at least in Daedalus

sshd in daedalus depends on libsystemd0, which may be satisfied by either the real libsystemd0 or by libelogind0 and libelogind-compat.
The former results in sshd being indirectly linked against liblzma as it is in Debian (though I'm not sure if that alone is enough to allow the exploit), the latter does not...

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

In any case this is largely academic, as daedalus never shipped the compromised xz versions.

Last edited by steve_v (2024-03-31 15:05:32)

uther · 2024-03-31 15:34:49

So effectively, both comments are correct depending on the exact set of packages you have installed. Devuan does pull sshd from Debian, so it does link against libsystemd. However the stripped-down copy of that library provided by elogind doesn't load liblzma, because its systemd-notify functionality is a stub.

Got it. I'm not worried about Daedalus, but Ceres.
I checked and I did NOT had libsystemd0 installed in my Ceres machine. Only the usual stub files that are found in Devuan stable and that would mean the sshd wasn't compromised. Do I understand it correctly?

Last edited by uther (2024-03-31 15:41:49)

steve_v · 2024-03-31 16:34:14

It's pretty trivial to just go check what /usr/sbin/sshd links against for yourself, is it not?

e.g.
with libsystemd0:

$ ldd /usr/sbin/sshd | egrep 'systemd|lzma'
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)

and with libelogind0 + libelogind-compat:

$ ldd /usr/sbin/sshd | egrep 'systemd|lzma'
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f8dfc5b8000)

ldd is not the be all and end all, but in this case it's fairly obvious whether or not liblzma (and a bunch of other extraneous crap systemd needs) is going to be loaded by sshd.

IOW:
Stable: Never shipped compromised xz packages.
Unstable/testing with libsystemd0: Probably as vulnerable as Debian.
Unstable/testing with elogind: Probably not vulnerable (but you should absolutely roll back to a pre-compromise xz anyway).

Aside, this is all assuming that sshd is the only target. It does look that way at the moment, but investigation is still underway.

Last edited by steve_v (2024-03-31 16:51:05)

quickfur · 2024-04-02 01:32:14

@steve_v: you're probably unaware of this, but this is what ldd's manpage says about using it on untrusted or potentially malicious executables:

Be aware that in some circumstances (e.g., where the program specifies an ELF interpreter other than ld-linux.so), some versions of ldd may attempt to obtain the dependency information by attempting to directly execute the program, which may lead to the execution of whatever code is defined in the program's ELF interpreter, and perhaps to execution of the program itself. (Before glibc 2.27, the upstream ldd implementation did this for example, although most distributions provided a modified version that did not.)
Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code. A safer alternative when dealing with untrusted executables is:
$ objdump -p /path/to/program | grep NEEDED
Note, however, that this alternative shows only the direct dependencies of the executable, while ldd shows the entire dependency tree of the executable.

In the case of the xz exploit, it's probably very unwise to use ldd to examine potentially affected executables.

steve_v · 2024-04-02 03:25:18

I'm well aware of ldd potentially executing code, however in this case:
This is stable install, with supposedly clean copy of liblzma & co.
It's also a disposable VM, because I'm not a complete idiot.
The point here is not to run ldd against compromised xz libs (everybody should have downgraded already on real systems), but to explain how liblzma is loaded into sshd and clear up the "devuan == safe" thing (which IMO is somewhat misleading).

liblzma is an indirect dependency here, so using objdump and friends instead is awkward.

jue-gen · 2024-04-03 06:10:47

Here is a timeline of what happened:
https://research.swtch.com/xz-timeline

jue-gen · 2024-04-06 20:30:59

This publication is also interesting for Devuan because it may confirm Devuan's philosophy:
https://www.wired.com/story/jia-tan-xz-backdoor/

alexkemp · 2024-04-07 08:45:38

Thank you jue-gen, a *very* interesting article.

jue-gen · 2024-04-07 10:56:19

And for the German speakers here, an interesting publication - also in relation to systemd:
https://dnip.ch/2024/04/02/xz-open-sour … wtab-de-de
Perhaps there is someone here who can evaluate systemd against this background.

nahkhiirmees · 2024-04-07 17:56:46

sshd in daedalus depends on libsystemd0, which may be satisfied by either the real libsystemd0 or by libelogind0 and libelogind-compat.

Planning to return using Chimaera anyway...

I recently noticed a) this thread and b)https://pkginfo.devuan.org/cgi-bin/pack … =2.03.16-2 .
Package lvm2 has libsystemd0 as a dependency. And in turn https://pkginfo.devuan.org/cgi-bin/pack … -1~deb12u1 libsystemd0 has liblzma5 as a dependency.

So, do i need to run sshd to be in danger or is using lvm2 enough? I prefer to be the one who knocks

Last edited by nahkhiirmees (2024-04-07 18:16:48)

Andre4freedom · 2024-04-07 18:05:50

In daedalus the dependency resolves to:

liblzma5 -->
5.4.1-0.2
http://deb.devuan.org/merged daedalus/main amd64

So no danger, stick to daedalus and no fancy experimental repos. (Only if you are a developer)

zapper · 2024-04-07 18:56:08

@jue-gen I had a feeling this was not going to affect devuan. Its awesome to know I was right.

I looked into the vulnerability and saw it used systemd. And devuan blocks that crap as much as possible, so I figured it wouldn't have any affect.

jue-gen · 2024-04-07 19:56:06

The malicious code arrived in Testing and Unstable. If it recognized that it had landed on a system that does not work with systemd, it did nothing. But it was still there. This is an obvious security problem. Malicious code lurking in the system. Nobody can say if, how and when it can become active and cause damage. Thank God it has been found. But that should be a lesson to us. Security will have to become more important in the future.

nahkhiirmees · 2024-04-07 20:18:27

Maybe moving on to Alpine becomes a good idea. I heard that in that distro there is not so much bloat or unnecessary dependencies.
But i have been using Debian-ish distros almost 20 years. It is not easy to walk away from that.

jue-gen · 2024-04-07 20:25:35

That can't be a solution either. Devuan is not the worst choice. I'm sticking to it. The malicious code never made it into stable. Security just needs to become more important in the future. The attacks will get much better. You have to be prepared for that.

pcalvert · 2024-04-08 16:08:25

nahkhiirmees wrote:

Maybe moving on to Alpine becomes a good idea.

I think it's worth considering. At the very least, you could install Alpine in a VM in order to become more familiar with it. That's what I'm planning to do. Even if I don't use it as my main OS, I may still use it for some other purpose.

Last edited by pcalvert (2024-04-09 08:00:39)

zapper · 2024-04-12 16:54:06

If I want a minimalistic system I have two choices...

OpenBSD or Hyperbola.

All the others don't seem minimal enough.

Devuan is not minimal enough, but I will definitely use it for ARM64 since Hyperbola don't support it.

ralph.ronnquist · 2024-04-12 22:13:06

Hey @zapper, a positive action on this forum would have been to propose the hands-on and/or package list to use from the Devuan repositories in order to have that "minimalistic system".

As you know, there is no single "Devuan System" as Devuan is a repository of packages that includes all Debian packages except those that are or relies on systemd; it is your choice.

zapper · 2024-04-13 00:11:30

@ralph.ronnquist

dbus, systemd, network-manager, pulseaudio, pipewire, wayland, avahi, java and their libraries being completely OPTIONAL is the only way I would think that devuan could meet that standard of what I would desire.

Aka, not needing those packages + their libraries would be my criteria.

If that cannot be reached, then it is mostly futile.

As for specific packages, those are the system ones that prevent a minimal devuan install but specifically which are okay in my book?

I cannot say completely, because I would have to wade through devuan to find them. It would be very tricky to specify them all given Devuan has 50K+ packages.

Probably less than 10K of them would fit my bill.

In any case, I am not sure what you meant by meeting a minimal system design.

My criteria are probably impossible for devuan unless signifiant changes were made.

And no i don't expect them to be met. This isn't for the faint of heart after all.

steve_v · 2024-04-13 09:13:57

zapper wrote:

If I want a minimalistic system I have two choices...
OpenBSD or Hyperbola.

... Or NixOS, Gentoo, CRUX, Gobo, FreeBSD, or any other system that provides tooling to build packages locally with the configuration you want.
Were you motivated enough to do so, this can also be achieved with Debian/Devuan... It's just a bunch more work as the packaging tools don't really cater to global feature switches the way e.g. Gentoo USE flags or the nixpkg declarative build system do.

What you're really asking for appears to be a binary distribution where all the configuration and packaging work is done for you, yet the choices the maintainers make are precisely aligned with your preferences... That's not going to happen, regardless of how much you complain about it.

You want the Devuan developers and maintainers to fork and rebuild everything to run without $things_you_dislike, yet you're not even willing to properly define what you want or what would be needed to achieve it?
Not to put too fine a point on things: Get off the grass.

The officially official Devuan Forum!

#1 2024-03-29 22:44:56

liblzma CVE-2024-3094

#2 2024-03-30 12:20:13

Re: liblzma CVE-2024-3094

#3 2024-03-30 16:04:30

Re: liblzma CVE-2024-3094

#4 2024-03-31 08:27:49

Re: liblzma CVE-2024-3094

#5 2024-03-31 13:12:55

Re: liblzma CVE-2024-3094

#6 2024-03-31 14:51:34

Re: liblzma CVE-2024-3094

#7 2024-03-31 15:34:49

Re: liblzma CVE-2024-3094

#8 2024-03-31 16:34:14

Re: liblzma CVE-2024-3094

#9 2024-04-02 01:32:14

Re: liblzma CVE-2024-3094

#10 2024-04-02 03:25:18

Re: liblzma CVE-2024-3094

#11 2024-04-03 06:10:47

Re: liblzma CVE-2024-3094

#12 2024-04-06 20:30:59

Re: liblzma CVE-2024-3094

#13 2024-04-07 08:45:38

Re: liblzma CVE-2024-3094

#14 2024-04-07 10:56:19

Re: liblzma CVE-2024-3094

#15 2024-04-07 17:56:46

Re: liblzma CVE-2024-3094

#16 2024-04-07 18:05:50

Re: liblzma CVE-2024-3094

#17 2024-04-07 18:56:08

Re: liblzma CVE-2024-3094

#18 2024-04-07 19:56:06

Re: liblzma CVE-2024-3094

#19 2024-04-07 20:18:27

Re: liblzma CVE-2024-3094

#20 2024-04-07 20:25:35

Re: liblzma CVE-2024-3094

#21 2024-04-08 16:08:25

Re: liblzma CVE-2024-3094

#22 2024-04-12 16:54:06

Re: liblzma CVE-2024-3094

#23 2024-04-12 22:13:06

Re: liblzma CVE-2024-3094

#24 2024-04-13 00:11:30

Re: liblzma CVE-2024-3094

#25 2024-04-13 09:13:57

Re: liblzma CVE-2024-3094

Board footer