Looking at IFUNC, there never seems to be a reason to allow function loading from a different library than the one the call is in, right? Maybe a restriction like that could be built in. Or just explicitly enumerate the possible substitutions per site.

Sure, but your solution supposes some kind of linking cop program overseeing the linking process, and who is going to keep the linking cop honest?

I mean dynamic loader is part of the base system and you generally trust the compiler and linker you build the program with. If any of those are malicious, you've already lost the game.

Asking a programmer to trust his own compiler and libraries which he can personally analyze and vouch for (static linking) is much different than asking the programmer to vouch for the dynamic libraries present on some given user’s machine.

Yes, the dynamic linker (/lib/ld-linux.so.2), which is one relatively short program as opposed to thousands of big ones. :)

The point is, there's simply no usecase to require or even allow the program to do IFUNC substitution freely on its own. A programming framework should not opt the developer in to capabilities they don't want or need. Much of C-likes' complexity arises from unnecessary, mandated capabilities.

IFUNC isn't used directly to patch the functions of another library here, it's just the entry point for the exploit code. IFUNC is used as opposed to other ways to execute code on library load because it runs very early (before linking tables are remapped read-only).

This particular approach of hooking would be much harder; but a malicious xz has other options as well. It's already in the code path used by dpkg when unpacking packages for security updates, so it could just modify the sshd binary, or maybe add a rootkit to the next kernel security update.

It seems foolish to change our systems to stop one of the steps the attacker used after their code was already running as root; the attacker can just pick something else; as root they have essentially unlimited options.

True, but such code changes in xz would be much easier to audit than all the dynamic loading shenanigans, even if obfuscated in the build system. The GNU's dynamic loader specially has grown to be very complicated (having all these OOP-like polymorphism features on linker / loader level ...) and I think we should tone down the usage of dynamic linking as I see it as low hanging fruit for attacks in general.

“It seems foolish to change”

Rejecting evidence in favor of retaining preconceptions is certainly popular.

There are other reasons to change, though. The main thing to consider here is that static linking is the "OG" way of doing things, and also the simplest and the most easily understandable one. There are also obvious perf benefits to it when it comes to optimizing compilers.

On the other hand, dynamic linking was originally more or less just a hack to deal with memory-restricted environments in the face of growing amounts of code. It was necessary at the time because we simply wouldn't have things like X or Windows without it way back when.

But RAM is nowhere near as sparse these days, and it could be even less so if there was a concerted push on hardware vendors to stop skimping on it. So why don't we remove the hack and get back to a simple model that is much easier to understand, implement, and audit?

agree, it’s difficult to believe that people believe in dynamic linking so strongly that they are unwilling to consider abandoning it even in the face of obvious problems like this xz situation