At this point “All libraries could be malicious” is a threat model that must be considered for something as security critical as OpenSSH.
At this point “All libraries could be malicious” is a threat model that must be considered for something as security critical as OpenSSH.
Keep in mind that upstream didn't even link to liblzma. Debian patched it to do so. OpenSSH should defend against that too?
This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.
Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1].
Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch.
1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...
What a complete failure of an init system's job, and the patch was applied due to systemd not resolving the issue in another way.
This is the problem with systemd. Way, way way too much complexity.
It's not a systemd issue, it's a larger cultural issue with packagers increasing attack surface to make their lives easier.
Both Redhat and Debian and others applied this patch as a result. People didn't do it "just cause".
https://bugzilla.redhat.com/show_bug.cgi?id=1381997
Jakub Jelen 2016-10-12 08:40:44 UTC
<snip>
> Why do you want to avoid sd_notify()?
Why to avoid this? Well, it is adding more systemd-specific bits and new build dependency to something that always worked well under other inits without any problems for years.
https://news.ycombinator.com/item?id=39878181
So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration.
I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch.
And Redhat, Fedora, Debian, Ubuntu, and endless other distros took this route, because something was required, and here we are. Something that would not be required if systemd could actually perform its job as an init system without endless work arounds.
Also see my other reply in this thread, re Redhat's patch.
After all, what you're saying is and has always been the case! It's like saying "Well, Ford had a design flaw in this Pinto, and sure 20 people died, but... like, cars have design flaws from time to time, so an accident like this would've happened eventually anyhow! Oh well!"
It doesn't jive in this context.
Directly speaking to this point, patched ssh was chosen for a reason. It was the lowest hanging fruit, with the greatest reward. Your speculation about other targets isn't unwarranted, but at the same time, entirely unvalidated.
That said, there are dozens of ways to fix this and it really seems like RedHat chose the worst one. They could have patched sshd in the other various ways listed in that ticket, or even just patch it to exit on SIGHUP and let systemd re-launch it.
(Some difficulty with this one though. For instance you probably have to ban running arbitrary code at load time, but you should do this anyway because it will stop people from writing C++.)
Darwin doesn't let you make library regions writable after dyld is finished with them. (Especially iOS where codesigning also prevents almost all other ways to get around this.)
Something like OpenBSD pledge() can also revoke access to it in general.
> But x86-64 got rid of the middle rings.
x86 is a particularly insecure architecture but there's no need for things to be that way. That's why I mentioned PAC, which prevents other processes (including the kernel) from forging pointers even if they can write to another process's memory.
So maybe just don't patch sshd?