3 ms·
Dynamic linking was a mistake and should be eliminated
by someguydave 3y ago
Dynamic linking was a mistake and should be eliminated
- intelVISA 3y agoyep, but how to reverse such a blunder?
- someguydave 3y agoWell step one is to just stop doing it? I guess someone will need to start publishing a static-only linux distro
- LtWorf 3y agoI think you don't fully understand how the attack works. Had sshd been written in go or rust, the attack would have still been possible.
- someguydave 3y agoof course, I never wrote otherwise?
- kbenson 3y agoThat this was dynamically linked is the least interesting thing about it IMO. It was a long term I filtration where they got legitimate commit access to a well used library. If xz was statically linked in some way, or just used as an executa Le to compress something (like the kernel), the same problems exist and no dynamic linking would need to be involved.
- Cloudef 3y agoNot true, it would be much harder to hook into openssl functions if the final executable was static [1], the only way is that if the openssl function this attack targeted, actually called a function from libxz. [1] https://sourceware.org/glibc/wiki/GNU_IFUNC https://sourceware.org/glibc/wiki/GNU_IFUNC Dynamic loading is relic of the past and cause of many headaches in linux ecosystem, in this case it also just obfuscates the execution path of the code more so you can't really rely on the code you are reading. Unfortunately I don't think it's possible to completely get rid of dynamic loading as some components such as GPU drivers require it, but it should be reduced to minimum.
- FeepingCreature 3y agoLooking 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.
- someguydave 3y agoSure, but your solution supposes some kind of linking cop program overseeing the linking process, and who is going to keep the linking cop honest?
- Cloudef 3y agoI 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.
- someguydave 3y agoAsking 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.
- FeepingCreature 3y agoYes, 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.
- account42 3y agoIFUNC 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).
- radiospiel 3y ago> If xz was statically linked in some way, or just used as an executa Le to compress something (like the kernel), the same problems exist and no dynamic linking would need to be involved. even more so: all binaries dynamically linking xz can be updated by installing a fixed library version. For statically linked binaries: not so much, each individual binary would have to be relinked, good luck with that.
- Cloudef 3y ago> For statically linked binaries: not so much, each individual binary would have to be relinked, good luck with that. Is essentially what all distros with sane build systems does.
- someguydave 3y agoIn exchange, each binary can be audited as a final product on its own merits, rather than leaving the final symbols-in-memory open to all kinds of dubious manipulation.