Am 08.06.11 12:33, schrieb Thiago Macieira: > On Wednesday, 8 de June de 2011 10:55:54 Till Oliver Knoll wrote: >> Well, let me elaborate: on Windows the equivalent of LD_LIBRARY_PATH is >> PATH. [...] > > You know, this was a vector attack on Windows last year. It affected Qt-based > applications, like VLC.
That was /exactly/ the case I had in mind when writing about "DLL injection" using LD_LIBRARY_PATH. ;) And it did not just affect Qt applications: *lots* of applications where affected, IIRC even Microsoft ones ;) But as you have clarified this won't work when the executable has setuid bit set (for privilege escalations, for example). > The problem is that PATH isn't searched last. After it, Windows searches the > current directory. PATH is really searched last, refer again to http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx "1. The directory where the executable module for the current process is located. 2. The current directory. 3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory. 4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory. 5. The directories listed in the PATH environment variable." So it is actually *even worse* than you describe: the Current Directory is /normally/ searched already in the 2nd place - even before the System and Windows folders! And that can't be stressed enough! Why on earth should an application search for DLLs in the Current Directory? Well, ask Microsoft ;) They realised this was a bad idea as well (but I guess due to compatibility reasons cannot undo that "design decision"). So there IS a compiler (or was it a registry entry? More likely...) switch which moves down the search order of the Current Directory (at least after the System and Windows folders, probably even after PATH). > Here's the attack method: > 1) user receives "Cool.zip" and unpacks it somewhere > > 2) the unpack contains two files: Cool.mp3 and wintab32.dll > > 3) the user double-clicks on Cool.mp3, which launches VLC from that directory > > Since the system doesn't have a Wacom tablet, so there's no wintab32.dll in > the system dirs. When Qt probes for the Wacom drivers, it tells the system to > LoadLibrary("wintab32") and that will be resolved on the current directory. Exactly - actually this "security flaw" is known since years (but people tend to forget ;) I think it gained "popularity" again last year since apparently loading DLLs also works from "network mapped drives" (or even WebDAV mounted drives - anything remotely accessible in any case, can't remember - I think that was a new feature or so, hence the popularity to exploit it again), so if an evil user could make another user click on said Cool.mp3 on that remote drive.... BANG! > ... >> 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!). > > No, you cannot force it. Why do you want to know more than the user? If the > user has set LD_LIBRARY_PATH, the user has a good reason to. Well, my idea was to prevent "library injections" from evil users who want to become root. But as you have already clarified this is not possible, since LD_LIBRARY_PATH is ignored if the executable has root privileges. But originally I did not even know about RUNPATH (just RPATH), and I simply wanted to avoid to set LD_LIBRARY_PATH in a startup script (no startup script at all), or even worse, have the user set it. So I changed my application to the more user-friendly RUNPATH ;) > > LD_LIBRARY_PATH does *not* affect setuid and setgid executables. The loader > skips it if geteuid() != getruid(). Right. So no danger in using LD_LIBRARY_PATH :) Cheers, Oliver _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
