Bruno Haible wrote:
Jacob Bachmeyer wrote:
some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly that, and ended up getting
xz-utils targeted as a means of getting to sshd without the OpenSSH
maintainers noticing.
The systemd people are working on reducing the libsystemd dependencies:
https://github.com/systemd/systemd/issues/32028
However, the question remains unanswered why it needs 3 different
compression libraries (liblzma, libzstd, and liblz4). Why would one
not suffice?
From reading other discussions, the only reason libsystemd pulls in
compression libraries at all is its "katamari" architecture: the
systemd journal can be optionally compressed with any of those
algorithms, and the support for reading the journal (which libsystemd
also provides) therefore requires support for all of them. No, sshd
(even with the distribution patches at issue) does /not/ use that
support whatsoever.
Better design would split libsystemd into separate libraries:
libsystemd-notify, libsystemd-journal, etc. I suspect that there are
more logically distinct modules that have been "katamaried" into one
excessively large library. The C runtime library has an excuse for
being such an agglomeration, but also note that libc has *zero* hard
external dependencies. You can ridicule NSS if you like, but NSS
modules are only loaded if NSS is used. (To be fair, sshd almost
certainly /does/ use functions provided by NSS.) The systemd developers
do not have that excuse, and their library *has* external dependencies.
I believe the systemd developers cite convenience as justification for
the practice, because apparently figuring out which libraries (out of a
set partitioned based on functionality) you need to link is "too hard"
for developers these days. (Perhaps that is the real reason they want
to replace X11?) That "convenience" nearly got all servers on the
Internet running the major distributions backdoored with critical
severity and we do not yet know exactly what the backdoor blob did. The
preliminary reports that it was an RCE backdoor that would pass commands
smuggled in public key material in SSH certificates to system(3) (as
root of course, since that is sshd's context at that stage) are
inconsistent with the slowdown that caused the backdoor to be
discovered. I doubt that SSH logins were using that code path, and the
SSH scanning botnets almost certainly are not presenting certificates,
yet it apparently (reports have been unclear on this point) was the
botnet scanning traffic that led to the discovery of sshd wasting
considerable CPU time in liblzma...
I am waiting for the proverbial other shoe to drop on that one.
-- Jacob
