On Wed, Apr 3, 2024 at 11:05 AM Toon Moene <t...@moene.org> wrote: > > Two questions arise (as far as I am concerned): > > 1. Do daemons like sshd *have* to be linked with shared libraries ? > Or could it be left to the security minded of the downstream > (binary) distributions to link it statically with known & proven > correct libraries ?
I like static linking personally, but it seems like glibc has made a decision that shared linking is much preferred over static. That said my guess is that this kind of attack would have been effective on any executable built as PIE. It relied on using an IFUNC hook to adjust the PLT entry for a different function. And, of course, most executables are built as PIE these days, because that is more secure against different kinds of attacks. > 2. Is it a limitation of the Unix / Linux daemon concept that, once > such a process needs root access, it has to have root access > *always* - even when performing trivial tasks like compressing > data ? > > I recall quite well (vis-a-vis question 2) that the VMS equivalent would > drop all privileges at the start of the code, and request only those > relevant when actually needed (e.g., to open a file for reading that was > owned by [the equivalent on VMS] of root - or perform other functions > that only root could do), and then drop them immediately afterwards again. Note that the attack really didn't have anything to do with compressing data. The library used an IFUNC to change the PLT of a different function, so it effectively took control of the code that verified the cryptographic key. The only part of the attack that involved compression was the fact that it happened to live in a compression library. And it wouldn't matter whether the code that verified the cryptographic key was run as root either; the effect of the attack was to say that the key was OK, and that sshd should execute the command, and of course that execution must be done on behalf of the requesting user, which (as I understand it) could be root. Ian
