Am 08.06.2011 um 09:28 schrieb Konstantin Tokarev <[email protected]>:
> > > 08.06.2011, 10:50, "Till Oliver Knoll" <[email protected]>: >> I can't imagine that LD_LIBRARY_PATH would even take precedence even over >> system default paths such as /usr/lib! > > Why are you surprised? > > For example, your application is bundled with it's own copy of Qt libs, and > there's system-wide installation of Qt libs in /usr/lib (or /usr/lib64). You > set LD_LIBRARY_PATH in start script and - voilà - your application loads > proper (bundled) libraries instead of system ones. Exactly for THIS reason I am surprised. ;) Well, let me elaborate: on Windows the equivalent of LD_LIBRARY_PATH is PATH. That is whenever an *.exe is loaded at some point in the "DLL search order" it will look into all the directories in PATH for the corresponding DLLs. In fact PATH is searched last: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx (For the sake of simplicity lets not talk about "dynamically loaded" libs with dlopen() and Co. Let's also ignore manifests, side-by-side assemblies etc. - and let's forget about the Current Directory on Windows, which potentially opens doors for the same security risk of "DLL injection" discussed here, because it is also searched for DLLs). The important point is that on Windows DLLs which are located in the executable's directory are always taken first, or in other words: a user can't simply modify the PATH environment variable and have it point to a malicious DLL ("DLL injection"). On Unix/Linux this is not the case: libs located in the executable's directory are not automatically picked up, unless set otherwise. Either via LD_LIBRARY_PATH or by setting the linker flag rpath/runpath. (But remember that setting rpath to a relative path such as "." or "./lib" is just as bad as having relative paths in LD_LIBRARY_PATH - from a security point of view. That is where $ORIGIN comes into play which is expanded at runtime to the absolute path of the binary's location, so setting $ORIGIN or $ORIGIN/lib as rpath (runpath) is fine.) So what really surprises me is that LD_LIBRARY_PATH apparently takes precedence over the rpath/runpath settings (that it takes precedence over the default system library locations such as /usr/lib is probably wanted and acceptable, but potentially also risky). That would mean there was NO way on Linux/Unix to make sure an executable is picking up a lib from a well-defined location! And simply pointing LD_LIBRARY_PATH to a malicious lib would open that lib instead of the proper one (and maybe that lib would even inherit root access!). Setting LD_LIBRARY_PATH in your own start script would not help: I would simply ignore your script and call the executable directly (or via my own malicious script). I am sure I am missing something here, so Captain Obvious please speak up :) Cheers, Oliver _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
