If I'm not mistaken putting DLLs in the same directory as the executable lets you do the same on Windows. Mods and cracks for videogames usually plant a fake DirectX dll in the game folder.
Absolutely correct. Although this was intentional behaviour, it was given a security advisory[1]. In practice it allowed all sorts of exploits, including dumping packed executables for cracking, as you say.
Yeah, but UNIX developers love namespace conflicts and hardcoded paths, so something as simple as "look for libs in the directory your binary is in" either never occurred to them or was rejected under various arbitrary concerns.
Huh? It has not been rejected -- it is up to compiler/linker what to put in RPATH, and you can totally set RPATH to $ORIGIN. There is a nice tool, chrpath, to do so. For example, java sets it to:
I believe the reason it does not happen by default is that binaries go to /usr/bin, and no .so files should appear there. Also it breaks when hardlinks are involved.
> I believe the reason it does not happen by default is that binaries go to /usr/bin, and no .so files should appear there. Also it breaks when hardlinks are involved.
I other words, nobody uses it. So many conflicts could be easily solved if applications dropped this retarded insistence on spreading files over the hierarchy by type, but they just keep doing it because they mistake tradition for wisdom.
In order to exploit this you need to be able to write to the directory where the binary is.
"Security" is trotted out as an arbitrary concern quite often because a lot of security people don't have any concept of risk analysis or cost/benefit. If it was up to them no one would ever do anything because that way they can't make a mistake.
