lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Sep 2010 17:30:28 +0200 From: "Stefan Kanthak" <stefan.kanthak@...go.de> To: "Christian Sciberras" <uuf6429@...il.com> Cc: full-disclosure@...ts.grok.org.uk Subject: Re: DLL hijacking POC (failed, see for yourself) Christian Sciberras wrote: >> and failed to use it right! > > Well, I suppose I could have used neat tricks such as specifically and > directly loading the "bad" dll. > But as much as security goes, those are cheap tricks. Wrong again! You dont need tricks, you need to understand Windows' DLL search order. > Besides, I did ask for suggestions why my tests "failed". Read again what I wrote, carefully this time! Hint: its just the next two lines! >> The "application directory" is ALWAYS the first one where both implicit >> (referenced in the binary) as well as explicit (via LoadLibrary()) > > I believe the correct term is "static" vs "dynamic". No. Guess where the D in DLL comes from! Static linking occurs when the linker builds a binary (this might be a DLL.-) using *.OBJ and *.LIB. Dynamic linking occurs when the loader loads a binary (again: this might be a DLL) into memory and resolves its dependencies. >> Next time, do your homework first! > > I did. And it worked out right. I proved my point that the issue relates to: > - loading nonexistent dlls - is a very bad practice Another misconception: nonexistent DLLs can and will NEVER be loaded. DLLs but can and are used to extend the functions of an application. Just think of a "modular" application where the modules are built as DLLs and loaded on demand. Its the responsibility of the application to load the right module/DLL from the right path and give appropriate feedback to its user on failure. > - loading from the wrong directory (CWD instead of base) - is wrong What is a "wrong" directory? Windows' DLL load order (as well as the EXE load order) are both well-known and documented and contain CWD from the very beginning. The latter is sad but true. > Furthermore, it proves my original point of why one needs > differentiation between filesystem zones: > a network should be an untrusted zone; executables should only run > when (eg) a user accepts > via a proper dialog, just like any web browser asks the user whether > he wants to "open" the download or not. SAFER a.k.a. Software Restriction Policies (available with EVERY supported version of Windows) allow the Administrator to control which executables (including DLLs) may be run: you can deny or allow execution to specified (UNC) paths as well as "internet zones". See <http://technet.microsoft.com/en-us/library/bb457006.aspx> and <http://technet.microsoft.com/en-us/windows/cc507878.aspx> > The fix doesn't concern the affected applications (though using the > correct code would be very nice of them), > it should go into how LoadLibrary(Ex) handle remote/insecure files. Stefan _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists