Shock! Horror! Bug found where Windows applications will open DLLs that are in the current working directory of a process!
Except it’s not a bug. It’s by design, and it’s existed since NT.
Microsoft is being smacked in the head by a required feature of Windows due to the initial weakness of the LoadLibrary call. If you don’t specify a path to the file to load, it uses the standard library search path.
Dear god, you would think that this was news. It is not news, nor has it been since the goddamned operating system shipped. Granted, the issue is severe, but the fact of the matter is if an application is executed using a working directory that isn’t under your control, then what can you do? if there are libraries in the same directory that launched the program that happen to share the name of system libraries then you’re hosed.
Hey, guess what asshole, if you link a linux binary with a search path containing ‘.’, then you get the same problem. It’s just as well that nobody links their binaries with -R. …. eh?
The documentation is blatant in this regard. I’ve known it was a security issue since I first learned of the LoadLibrary call, as any even half decent developer should have known when they started using the damned function.
The rule is simple. Resolve the full path to a library before you load it. Validate that it ‘looks right’ at that point. Then load it.
BTW .init section in .so files – so totally a security hole. You can’t dlopen a file to determine if it’s good without executing the .init code. Game over man, game f**king over!
My .init code does a setenv(“LD_LIBRARY_PATH”, “.” + getenv(“LD_LIBRARY_PATH”)) … now piss off and write secure code for once…