full-disclosure - Re: DLL hijacking POC (failed, see for yourself)

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/