Re: [Full-disclosure] 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 <> and

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.


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Relevant Pages

  • noncontinuable exception during process load
    ... the load order is important. ... minor as installing some hotfix on the system involving one of the DLL ... >> bug reported to us about 1 month back. ... winmm attempts to load a driver ...
  • Re: mutual dependent DLLs and global variables
    ... >The problem is that minor tweaks in the dependency relationships can change the load order ... >initializers. ... I've had to track these down, sometimes because I'd introduced a dependency ... Ugh, assuming the DLLs really did form a DAG, it sounds like a DLL X was ...
  • Re: Cannot activate sbcl
    ... but I think what happens is that Windows sees that your executable has a DATA section that might overlap a DLL's address space then it would reallocate that DLL to different address space. ... VirtualAlloc dynamically in your code is that your program and all its ... What can be done here is to have many tiny executables with different BSS sections in them, which then load a bigger executable in the form of a DLL. ...
  • Re: Why do we need executables in certain formats ?
    ... > Can anybody explain me why do we need executables in certain formats? ... Modern virtual memory processors can locate to ... ..DLL files changed out from under them, ...
  • Re: Dynamic linking with symbols
    ... And a dll which ... > two different executables. ... Try putting your "exported code" into a static library which your ... EXE links against. ...