Re:The failed attempt to backdoor SSH globally – that got ca...
by inopinatus on Monday April 01, 2024 @05:33AM
(#39892261)
This is another furphy, because OpenSSH proper neither requires nor uses xz/lzma. It's made clear in Andres Freund's original report¹ that the libsystemd dependency dragging it along arises from distros patching openssh to support systemd notifications. The sad part is that systemd notifications are just a datagram on a socket, so using libsystemd for this is reminiscent of Joe Armstrong's banana.
Re:The failed attempt to backdoor SSH globally – that got ca...
by LtWorf on Monday April 01, 2024 @05:42AM
(#39892314)
As many have already pointed out, the library can also be linked to sshd via selinux.
Re:The failed attempt to backdoor SSH globally – that got ca...
by inopinatus on Monday April 01, 2024 @05:57AM
(#39892388)
I've seen that ambit claim too, but I'm not even sure what distro(s) it is referring to since I'm unable to confirm it on any host where I have ldd casually to hand. Ref however https://seclists.org/oss-sec/2024/q1/356
Re:The failed attempt to backdoor SSH globally – that got ca...
by usr1106 on Monday April 01, 2024 @08:11AM
(#39893266)
That packaging error makes liblzma being pulled in at installation (well, it's probably already there if pid 1 requires it). But it will not make the sshd binary use it. So I think the original claim stands: Without patching sshd for the notification it will not use liblzma.
Disclaimer: I did not search for all possible occurrences of dlopen().
Re:The failed attempt to backdoor SSH globally – that got ca...
by himinlomax on Monday April 01, 2024 @10:54AM
(#39894765)
https://github.com/proposal-signals/proposal-signals
> libselinux does not link to liblzma. It turns out the confusion was because of an old downstream-only patch in Fedora and a stale dependency in the RPM spec which persisted long-beyond its removal.
Re:The failed attempt to backdoor SSH globally – that got ca...
by xxs on Monday April 01, 2024 @06:46AM
(#39892654)
I get the sentiment. zstd is just better, though!
Other than that I did try a manual port (of zstd) to Java but I was not pleased with the results.
The other part is that systemd uses plain unix sockets with the most basic of protocols (that part along with docker forwarder was doable)
What could possibly go wrong. I'm sure there's no history of compression tools having serious vulnerabilities due to implementation errors...