The officially official Devuan Forum!

You are not logged in.

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

uther
Member
Registered: 2019-05-16
Posts: 73  

liblzma CVE-2024-3094

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.


soystemd-free diet

Offline

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

stopAI
Member
Registered: 2023-04-04
Posts: 187  

Re: liblzma CVE-2024-3094

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)

Offline

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

uther
Member
Registered: 2019-05-16
Posts: 73  

Re: liblzma CVE-2024-3094

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.


soystemd-free diet

Offline

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

jue-gen
Member
Registered: 2022-07-07
Posts: 122  

Re: liblzma CVE-2024-3094

Offline

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

uther
Member
Registered: 2019-05-16
Posts: 73  

Re: liblzma CVE-2024-3094

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


soystemd-free diet

Offline

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

steve_v
Member
Registered: 2018-01-11
Posts: 390  

Re: liblzma CVE-2024-3094

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)


Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

Offline

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

uther
Member
Registered: 2019-05-16
Posts: 73  

Re: liblzma CVE-2024-3094

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)


soystemd-free diet

Offline

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

steve_v
Member
Registered: 2018-01-11
Posts: 390  

Re: liblzma CVE-2024-3094

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)


Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

Offline

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

quickfur
Member
Registered: 2023-12-14
Posts: 438  

Re: liblzma CVE-2024-3094

@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.

Offline

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

steve_v
Member
Registered: 2018-01-11
Posts: 390  

Re: liblzma CVE-2024-3094

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.


Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

Offline

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

jue-gen
Member
Registered: 2022-07-07
Posts: 122  

Re: liblzma CVE-2024-3094

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

Offline

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

jue-gen
Member
Registered: 2022-07-07
Posts: 122  

Re: liblzma CVE-2024-3094

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

Offline

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

alexkemp
Member
Registered: 2018-05-14
Posts: 357  

Re: liblzma CVE-2024-3094

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

Online

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

jue-gen
Member
Registered: 2022-07-07
Posts: 122  

Re: liblzma CVE-2024-3094

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.

Offline

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

nahkhiirmees
Member
Registered: 2022-07-24
Posts: 261  

Re: liblzma CVE-2024-3094

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 smile

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

Offline

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

Andre4freedom
Member
Registered: 2017-11-15
Posts: 175  

Re: liblzma CVE-2024-3094

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)

Offline

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

zapper
Member
Registered: 2017-05-29
Posts: 972  

Re: liblzma CVE-2024-3094

@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.

big_smile


Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term  If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!

Offline

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

jue-gen
Member
Registered: 2022-07-07
Posts: 122  

Re: liblzma CVE-2024-3094

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.

Offline

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

nahkhiirmees
Member
Registered: 2022-07-24
Posts: 261  

Re: liblzma CVE-2024-3094

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.

Offline

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

jue-gen
Member
Registered: 2022-07-07
Posts: 122  

Re: liblzma CVE-2024-3094

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.

Offline

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

pcalvert
Member
Registered: 2017-05-15
Posts: 216  

Re: liblzma CVE-2024-3094

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)


Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Another one is called Luxxle.

Offline

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

zapper
Member
Registered: 2017-05-29
Posts: 972  

Re: liblzma CVE-2024-3094

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.


Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term  If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!

Offline

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

ralph.ronnquist
Administrator
From: Battery Point, Tasmania, AUS
Registered: 2016-11-30
Posts: 1,268  

Re: liblzma CVE-2024-3094

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.

Offline

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

zapper
Member
Registered: 2017-05-29
Posts: 972  

Re: liblzma CVE-2024-3094

@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.

wink


Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term  If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!

Offline

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

steve_v
Member
Registered: 2018-01-11
Posts: 390  

Re: liblzma CVE-2024-3094

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. roll


Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

Offline

Board footer