backdoor targeting deb and rpm via systemd?

Kelsoo · 2024-03-29 23:48:16

To be expected I guess

As one Slackware use said

The malicious code is inserted only when building a deb or rpm package of xz. Probably because some systemd based distros patch openssh to use liblzma (part of xz) and the idea is to have a backdoor in sshd.

Another reason why the traditional diversity of "Linux" was a good thing. The more we fly head first into the corporate monoculture the more we will see thing like this imo.

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

devur · 2024-03-30 09:26:57

i also read that message but not quite sure what to make of it as information relevant to the security of my devuan no systems pc when i search for 'liblxma' i get the following result, is there a problem with this.

/usr/share/doc/liblzma5
/lib/x86_64-linux-gnu/liblzma.so.5
/lib/x86_64-linux-gnu/liblzma.so.5.4.1
/var/lib/dpkg/info/liblzma5:amd64.list
/var/lib/dpkg/info/liblzma5:amd64.md5sums
/var/lib/dpkg/info/liblzma5:amd64.shlibs
/var/lib/dpkg/info/liblzma5:amd64.symbols
/var/lib/dpkg/info/liblzma5:amd64.triggers

rolfie · 2024-03-30 09:40:04

Affected is Testing, not Stable or older.

steve_v · 2024-03-30 10:37:53

targeting deb and rpm via systemd?

More accurately, targeting sshd (so far, anyway) via a vulnerable understaffed/funded project which just happens to provide attack surface because certain distros patched a security-critical package to add gratuitous linkage to systemd.

This is not about diversity, or even systemd specifically. It's about dependency bloat.

There is zero reason sshd needs to link against anything in systemd, let alone pull in liblzma just to support systemd-notify (and linking a full blown compression lib just to say "sshd is up" to systemd is another level of insane to begin with). Doing this kind of thing opens it up not only to vulnerabilities in such direct dependencies, but also the 9000 other frivolous things those in turn link to.

This is a perfect example of why anyone serious about security resists bloat and feature-creep. Without the ridiculous "because it's there" attitude of the distros involved (particularly WRT systemd integration), this exploit would not have been possible.
If sshd really needed systemd-notify support (and it doesn't), it should have been via a minimal implementation in sshd itself, not pulling in a bunch of bloat and a compression library essentially maintained by one dude.
Distros patching this kind of stuff in downstream is, frankly, pretty irresponsible.

For a quick illumination of just how out of hand this is getting in Debian/Devuan...

$ cat /etc/os-release; ldd /usr/sbin/sshd 
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
NAME="Devuan GNU/Linux"
VERSION_ID="5"
VERSION="5 (daedalus)"
VERSION_CODENAME="daedalus"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
        linux-vdso.so.1 (0x00007ffc96fde000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f27a6768000)
        libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f27a675c000)
        libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f27a672b000)
        libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f27a6719000)
        libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f27a6649000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f27a6619000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f27a65c7000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f27a64ed000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f27a64e7000)
        libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f27a6000000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f27a64c8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27a5e1f000)
        libnsl.so.2 => /usr/lib/x86_64-linux-gnu/libnsl.so.2 (0x00007f27a64ab000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f27a64a3000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f27a6497000)
        libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f27a5cd8000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f27a5ca9000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f27a5bed000)
        liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f27a5bc7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f27a68ec000)
        libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f27a5b2d000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f27a5b00000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f27a6487000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f27a5af9000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f27a5ae8000)
        libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007f27a5aba000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f27a5a92000)

$ cat /etc/os-release; ldd /usr/sbin/sshd 
NAME=Gentoo
ID=gentoo
PRETTY_NAME="Gentoo Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.gentoo.org/"
SUPPORT_URL="https://www.gentoo.org/support/"
BUG_REPORT_URL="https://bugs.gentoo.org/"
VERSION_ID="2.14"
        linux-vdso.so.1 (0x00007ffd3cde1000)
        libcrypt.so.2 => /usr/lib64/libcrypt.so.2 (0x00007f18fdd74000)
        libpam.so.0 => /usr/lib64/libpam.so.0 (0x00007f18fdd63000)
        libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f18fd800000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f18fdd47000)
        libc.so.6 => /usr/lib64/libc.so.6 (0x00007f18fd62f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f18fdec5000)

Which of these do you think has the larger attack surface, or more vulnerable supply-chain? I'm not even trying with that Gentoo build, and I could easily drop pam if I did.

Last edited by steve_v (2024-03-30 11:34:32)

Kelsoo · 2024-03-30 23:46:24

Yeah I could have been clearer. Considering I was pissed as a fart (home made dandelion and home made parsnip wine) I don't think I got to much wrong. Anyway more juice. :-)

https://www.redhat.com/en/blog/urgent-s … hide-users
https://gist.github.com/thesamesam/2239 … 78baad9e27

Last edited by Kelsoo (2024-03-30 23:46:53)

stultumanto · 2024-04-01 18:06:38

The avalanche of dependencies that occurs if you accept the "recommended" packages for ssh-server on Debian is truly mind-boggling. The exact list might change depending on your system, but it wanted to pull in an entire GNOME desktop on mine, and I didn't even have X installed! It was all because polkitd recommended a little GUI authentication widget.

quickfur · 2024-04-05 18:01:21

I almost always run apt-get with --no-install-recommends, because a lot of "recommended" packages are really needless bloat that I have no need of.

After this fiasco I'm almost ready to switch to a source-only distro, which I'd configure by hand to contain the absolute minimum options I need to do what I need to do, and nothing else. Even after getting rid of systemd too many Debian packages still come with too many things enabled by default. Mostly useless things that I never actually use.

kaiyel · 2024-04-09 16:26:08

Steve_V is on target :

This is not about diversity, or even systemd specifically. It's about dependency bloat.

That being said, as I read through the Openwall thread, I have the sense that the author of the backdoor specifically targeted dependency bloat accommodation as the vector for attack. As "do one thing, well" was set aside for systemd, increased dependencies are not only expected but required, and being non-paranoid about them widens the attack angle, nearly allowing a tangential xz/liblzma to be used as a tool to compromise openssh. Wow.

If xz/liblzma can be so used, what other dependencies have been introduced that are also tangential, but because they are not systemd specific their inclusion is not pruned out of Devuan? As Devuan evolves I fear it must not only guard against systemd in the upstream specifically, but also the dependency bloat the upstream has permitted in order to accommodate systemd.

Dependencies of dependencies ... it's a new kind of "dependency hell" :-)

--K

quickfur · 2024-04-10 01:24:58

Dependencies are inherently evil. Did you know that versioned dependencies are an NP-complete problem? As in, if you have a graph of projects that have versioned dependencies on each other, resolving these dependencies potentially require an exponential-time (or exponential-space) algorithm. Dependency hell indeed!

In my own code projects, I prefer having no dependencies at all. Of course, this isn't always possible; so the next best thing is shallow dependencies: those that only require 1 level of dependencies. Actually, before I even get to dependencies, my preference is single-file modules that I can just copy into my source directory and use as-is, without declaring any dependencies. Not many things can be used this way, but when such exist, I prefer it. Only if I have no choice, I'll go with a shallow dependency. And of course, the fewer dependencies the better. Recursive dependencies I try to avoid like the plague unless there's absolutely no way around it. And I absolutely would not touch an automatic dependency system that will automatically download 500 packages in response to a single dependency on some package that's promiscuous in its recursive dependencies. Those things are pure evil.

See also this link that describes a lot of the issues that come with dependencies, that people have been ignoring for far too long: https://research.swtch.com/deps

Last edited by quickfur (2024-04-10 01:27:11)

nahkhiirmees · 2024-04-10 21:27:11

Sometimes i'm also troubled by dependencies. Though usually dependencies that trouble me have something to do with Docker, pypi or node.
For example, do i really need to have 600 mb container just to run a simple "hello world"-app with Flask ? Or download 100 Python packages for that? And can i trust that the packages i download today even work? And without side-effects?

Last edited by nahkhiirmees (2024-04-10 21:27:38)

nahkhiirmees · 2024-04-10 22:57:51

Btw. found this pdf: https://edolstra.github.io/pubs/phd-thesis.pdf I think it is loosely related to that dependency-subject.
Found it from the links-section of https://en.wikipedia.org/wiki/GNU_Guix . Seems intresting distro, init diversity and a different package manager.
Seems to need a bit of effort to make it useful though.

steve_v · 2024-04-11 06:43:21

Personally I have no problem with library dependencies and dynamic linking, where it adds legitimately useful functionality and reduces code duplication.

But that's not what this is. Supporting sd_notify is little more than sending a simple datagram to a unix socket, and pulling in libsystemd0 for that one function is just about the definition of gratuitous attack surface.
But hey, why not double down, ignore the fact upstream has already said no because they don't want the dependency bloat, and go and patch it in regardless. The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Then there's that other obvious elephant of course: why does init need an LZMA (de)compressor anyway? Init's job is managing daemons, nothing more... Right?

IMO far too many projects pull in dependencies because it's the easy way to implement a feature, with precious little regard for whether it's a good way... or whether that feature is even worth having to begin with.
That includes distro packagers turning on every optional build-time dependency flag they can find, which is a long-time gripe of mine WRT Debian. Patching upstream sources for even more dependencies is just taking this trend to its (il)logical conclusion.

Last edited by steve_v (2024-04-11 07:10:34)

Altoid · 2024-04-11 12:39:49

Hello:

steve_v wrote:

The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Quite so.

Best,

A.

kaiyel · 2024-04-12 21:09:43

steve_v wrote:
The "systemd exists, so everything should use it somehow" bandwagon must grind ever onward.

Knowing that is to be expected, and thinking out loud, how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd? Could it even be done without forking packages expressly for that purpose?

Devuan packaging may gain a tertiary goal beyond pruning systemd and maintaining user choice ... eliminating permissive bloat. I understand this is no small task and I imagine there are not yet enough packaging hands to accomplish this. Still, it feels that is the path Devuan will be given no choice but to follow.

Another caveat under the "Packaging Guide for Devuan" may be necessary under the section "Package Forking Policy" to welcome forks to eliminate permissive bloat as the manpower is found to do so. https://git.devuan.org/devuan/documenta … ngGuide.md

As a RedHat transplant, I'm not competent yet to provide another set of hands in that arena here. But I take this adventure with openssh as encouragement to plan ahead, learn more, and reach that level.

--K

zapper · 2024-04-13 00:22:31

@quick fur it is pure evil, and to be fair, these linux frameworks are also pure evil, polkit, systemd, avahi, dbus, networkmanager, pulseaudio, pipewire, wayland, java and their libraries are very often forced regardless of if the user needs them or not or for that matter... WANTS them...

This is why devuan cannot be used minimally and still have what i consider to be the correct functionality.

Too many debian inherited crapstorms. Its not devuan's fault, its debian's and all the other egregious devs who are like, "don't rock the boat" towards these bs corporate influencers. Redhat is a perfect example of why YOU NEED to ROCK THE BOAT! Same with Microsoft and Google and Apple.

They need to be told to suck it and force them to gag on it.

steve_v · 2024-04-13 08:05:10

kaiyel wrote:

how does Devuan avert attack surface expansion while the upstream becomes more dependency permissive to accommodate systemd? Could it even be done without forking packages expressly for that purpose?

IMO (at least as a general problem), it doesn't and it can't. Most dependencies are decided on at compile-time, and changing them means forking (or at least rebuilding) packages.
Frankly I don't see where Devuan is going to get the manpower for that. It might be feasible to fork some particularly important packages where all that is required is a simple configure flag change or dropping a patch, but deciding where to draw the line is well beyond my pay grade.

IMO the better approach is probably working on projects like elogind, i.e. forking parts of systemd itself, keeping the good bits and replacing all the crap we don't want with ABI-compatible stub functions.
That's something that is and can continue to be a common effort between distros, and so long as it keeps up with systemd changes it should allow most packages from e.g. upstream Debian to be used as-is in Devuan.

The downside of course is that we'll have to keep fending off nutters grinding the "Why does Devuan have libsystemd0" axe without bothering to check where that lib actually comes from or what it does.

zapper wrote:

polkit, systemd, avahi, dbus, networkmanager, pulseaudio, pipewire, wayland, java and their libraries
...
devuan cannot be used minimally and still have what i consider to be the correct functionality

You won't get both minimal dependencies and "correct" functionality with any binary distribution that in any way targets mainstream desktop use cases.

Desktop users want, at least for the most part, low-effort GUI support for things like wireless hotspots, VPNs, bluetooth / hotplug audio devices, network discovery, and prompt-free permission elevation for common tasks. In the current ecosystem that means using some or all of the "evil" frameworks you list.
This has nothing to do with "corporate influencers", it's simply the result of trying to cater to end-user expectations without massive code duplication or packaging workload.

That leaves either distributions that cater to minimalism specifically (which discounts most Debian derivatives and general-purpose distros right away) or building from source (i.e. Gentoo and derivatives).

Bitching about "bs corporate" whatever at every opportunity achieves exactly nothing. The only realistic way to have your cake and eat it (aka have only the features and dependencies you want) is to either rebuild all the affected packages yourself or switch to a source-based meta-distro.

zapper wrote:

They need to be told to suck it and force them to gag on it.

So why don't you go do that then. Ranting here is utterly futile, and serves only to bloat the thread with unproductive noise.
If you must vent your non-specific anti-corporate rage, I suggest you write your $government_representative.

Last edited by steve_v (2024-04-13 08:44:24)

zapper · 2024-04-14 04:47:48

@steve_e yes but I am not patient enough nor skilled enough to rebuild it all myself.

Also, my voice alone would not accomplish anything, for government change or corporate change.

The only thing I can really do is try to open eyes or resist that which is ugly and unneeded.

I am not against having more packages, I am merely against automatically assuming everyone should have to have dependencies that aren't necessary,

Ie, required dependencies should only be for packages that actually need them, not packages that optionally use them or need them.

But yeah, saying all this here probably won't change much. Its futility unless enough people wake up though in general.

But I do agree, partially with you. It would be too much work for devuan developers to fix these problems in devuan... well at least without becoming an independent distro anyhow but I don't expect that until all other options become invalid/unworkable.

The bare minimum line should be making all libraries optional for those dependencies I mentioed, the linux frameworks or at least have an option to make them optional.

But this has gotten tedious this comment thread.

steve_v · 2024-04-14 06:08:55

The only thing I can really do is try to open eyes
...
saying all this here probably won't change much. Its futility unless enough people wake up though in general.

AKA, lots of preaching with very little doing.

The bare minimum line should be making all libraries optional for those dependencies I mentioed

In many cases these frameworks are already optional, via compile-time flags... Something which, for reasons that apparently escape me, you seem completely unwilling to consider.
Where they are not optional at compile-time, patches to upstream code would be required.

There is no standard facilty for making dynamic-linked library dependencies optional at runtime, because that's not how any of this works. The thing that is becoming most tedious of all is your insistence that there shouid be such a feature, and somebody other than you should see to it.

If you want everything built for you and served up in convenient packages, you get whatever the packagers decided on when they built them (or engage in constructive discussion where you disagree).
If you want control over compile-time options and patches, you run Gentoo or some other source-based distro.

Anything else is just blowing smoke. The tools to build a system the way you want already exist, if you're willing to put in the effort to use them.
Have you actually built and used a system without dbus and policykit, or is this all just idological bikeshedding?

All that said, if you want to be taken even remotely seriously on the idea of making such dependencies optional at the package management level (which would entail binary distros maintaining multiple variants of each affected package):
* What is your convincing technical argument for such a change?
* What do you propose replacing the projects on your "evil" list with? You want to drop dbus for example, so how should we do IPC?
* And, how is your proposed replacement (functionally) superior?
* How do you propose convincing 1000 upstream projects to drop features dependent on $evil_library or switch to your replacement?
* Who is going to do all this work, and does the benefit justify it? If upstreams aren't on board, who is going to write and test patches?

Last edited by steve_v (2024-04-14 06:33:40)

zapper · 2024-04-14 20:11:53

@steve_v probsably true not alot of doing. Idk, all the questions posed here are a lot to even ponder let alone fix. I know only one distro that has done any of this as previously stated. So... yeah its a mess.

The officially official Devuan Forum!

#1 2024-03-29 23:48:16

backdoor targeting deb and rpm via systemd?

#2 2024-03-30 09:26:57

Re: backdoor targeting deb and rpm via systemd?

#3 2024-03-30 09:40:04

Re: backdoor targeting deb and rpm via systemd?

#4 2024-03-30 10:37:53

Re: backdoor targeting deb and rpm via systemd?

#5 2024-03-30 23:46:24

Re: backdoor targeting deb and rpm via systemd?

#6 2024-04-01 18:06:38

Re: backdoor targeting deb and rpm via systemd?

#7 2024-04-05 18:01:21

Re: backdoor targeting deb and rpm via systemd?

#8 2024-04-09 16:26:08

Re: backdoor targeting deb and rpm via systemd?

#9 2024-04-10 01:24:58

Re: backdoor targeting deb and rpm via systemd?

#10 2024-04-10 21:27:11

Re: backdoor targeting deb and rpm via systemd?

#11 2024-04-10 22:57:51

Re: backdoor targeting deb and rpm via systemd?

#12 2024-04-11 06:43:21

Re: backdoor targeting deb and rpm via systemd?

#13 2024-04-11 12:39:49

Re: backdoor targeting deb and rpm via systemd?

#14 2024-04-12 21:09:43

Re: backdoor targeting deb and rpm via systemd?

#15 2024-04-13 00:22:31

Re: backdoor targeting deb and rpm via systemd?

#16 2024-04-13 08:05:10

Re: backdoor targeting deb and rpm via systemd?

#17 2024-04-14 04:47:48

Re: backdoor targeting deb and rpm via systemd?

#18 2024-04-14 06:08:55

Re: backdoor targeting deb and rpm via systemd?

#19 2024-04-14 20:11:53

Re: backdoor targeting deb and rpm via systemd?

Board footer