5 ms·

The specific way sshd was infected would not have happened with libxz as dlopen library. Debian's sshd only uses libsystemd for the notify api. I.e. it doesn't

by ongy 2y ago

The specific way sshd was infected would not have happened with libxz as dlopen library. Debian's sshd only uses libsystemd for the notify api. I.e. it doesn't need any feature that uses libxz. If it's dlopen()ed, it does not need to be loaded into the process context to use an unrelated feature. FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX.

newpavlov 2y ago
sshd should not have used libsystemd in the first place for the trivial notification. And the ifunc stuff is its own security nightmare. Papering over this by dlopen-ing some libs in libsystemd does not address the deeper issues.
NewJazz 2y ago
FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX. They've done the exact opposite afaict. Libsysd used to be split up, now it is monolithic.
Tuna-Fish 2y ago
> FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX. FWIW, upstream systemd has the opinion that no-one should load the library for startup notification, instead they should use the well documented api and just write a message to a socket.
- idoubtit 2y ago
  Indeed, that's what the Debian maintainer of OpenSSH did soon after the quick security fix. He replaced the dependency on libsystemd with some hand-made code that notifies systemd by socket. https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37cb8405cba624a133f4b8f464fbe381c5c8 https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37cb8...
- ptx 2y ago
  That's not what they said in their update to the documentation[0] last week, which says that "although using libsystemd is a good choice, this protocol can also be reimplemented without external dependencies". It calls it a "good choice". Did they say somewhere else that no-one should do it despite it supposedly being a good choice? [0] https://github.com/systemd/systemd/pull/32030/files https://github.com/systemd/systemd/pull/32030/files
  - klooney 2y ago
    Yes- https://mastodon.social/@pid_eins/112202696589971319 https://mastodon.social/@pid_eins/112202696589971319
marcosdumay 2y ago
Upstream systemd should just cut the unused crap from their notification protocol and promise it's stable. They probably couldn't change it anymore if they tried to.
- Denvercoder9 2y ago
  The systemd notification protocol has been stable and documented as such for years (probably even a decade at this point): https://systemd.io/PORTABILITY_AND_STABILITY/ https://systemd.io/PORTABILITY_AND_STABILITY/
- klooney 2y ago
  The whole protocol is "write READY=1 to the socket found in the NOTIFY_SOCKET environment variable".

by ongy 2y ago

newpavlov 2y ago

sshd should not have used libsystemd in the first place for the trivial notification. And the ifunc stuff is its own security nightmare. Papering over this by dlopen-ing some libs in libsystemd does not address the deeper issues.

NewJazz 2y ago

FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX. They've done the exact opposite afaict. Libsysd used to be split up, now it is monolithic.

Tuna-Fish 2y ago

> FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX. FWIW, upstream systemd has the opinion that no-one should load the library for startup notification, instead they should use the well documented api and just write a message to a socket.

idoubtit 2y ago
Indeed, that's what the Debian maintainer of OpenSSH did soon after the quick security fix. He replaced the dependency on libsystemd with some hand-made code that notifies systemd by socket. https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37cb8405cba624a133f4b8f464fbe381c5c8 https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37cb8...
ptx 2y ago
That's not what they said in their update to the documentation[0] last week, which says that "although using libsystemd is a good choice, this protocol can also be reimplemented without external dependencies". It calls it a "good choice". Did they say somewhere else that no-one should do it despite it supposedly being a good choice? [0] https://github.com/systemd/systemd/pull/32030/files https://github.com/systemd/systemd/pull/32030/files
- klooney 2y ago
  Yes- https://mastodon.social/@pid_eins/112202696589971319 https://mastodon.social/@pid_eins/112202696589971319

marcosdumay 2y ago

Upstream systemd should just cut the unused crap from their notification protocol and promise it's stable. They probably couldn't change it anymore if they tried to.

Denvercoder9 2y ago
The systemd notification protocol has been stable and documented as such for years (probably even a decade at this point): https://systemd.io/PORTABILITY_AND_STABILITY/ https://systemd.io/PORTABILITY_AND_STABILITY/
klooney 2y ago
The whole protocol is "write READY=1 to the socket found in the NOTIFY_SOCKET environment variable".