Free software's not-so-eXZellent adventure

Yea, then possibly it would make sense to pick some other target than the dynamic linker for such hooking. From a quick look, RSA_public_decrypt() behind the scenes is a function pointer call, so swapping out a pointer to the ops structure in struct RSA would suffice. CRYPTO_set_mem_functions() could be used to set a custom malloc implementation to help locating potential struct RSA candidates.

Another idea that comes to mind is fopencookie() could be used to hook stdout/stderr and use that to deliver the payload (assuming sshd includes enough info there about failed connection attempts)... there's just so many different opportunities. Also detection chances could probably be reduced by simply disabling the backdoor for say, 90% of the connections (pthread_atfork() perhaps) while still remaining useful.

I think everyone's also missing the point that this ifunc or .init method also allows highly indirect dependencies to gain control of early stage execution even if the execution would never have got into that library. This feature is what makes indirect dependencies so dangerous. For ifunc, the solution looks like it should be that if you have lazy symbol resolution (the default), we shouldn't call the ifunc to perform the choice test until we actually need to resolve the symbol (so if we never need the symbol it's never called). I think it would also be highly desirable not to call library .init functions until the first symbol in the library is hit (this one is more problematic since they generally expect to be run before the actual main() routine is called).

> They might well be, but that's irrelevant since once you have an adversarial foothold in some library or other, running as root, you can do pretty much anything anyway, ifunc or .init or hijacked symbol.

(ignoring the "running as root" clause)

I think this is maybe getting to the nub of it: if you link with a library, are you implicitly trusting it, to the extent that you're willing for it to write all over "your" memory, including code?

It's possible that for some of us who are used to thinking in terms of microservices, containers, etc etc, it doesn't seem hard to imagine a world where the answer is "no, I'm not trusting it that far - it can have its own memory, just like it has its own namespace, and its own scopes, but it doesn't get to interfere with mine". To me, it seems pretty crazy that all these languages typically enforce lexical scoping rules, but apparently glibc, with a combination of ifuncs and audit hooks, allows complete violation of the compartmentalisation that lexical scoping creates.

For some of us who are (I'm guessing) more experienced C/C++/kernel devs, there's both tradition, and good reason as to why believing/hoping/pretending the trust isn't absolute, is misguided.