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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTi=vadPm_H2x85-N7spDTztCPEC-ekTueT_Sifu1@mail.gmail.com>
Date: Wed, 15 Sep 2010 02:41:15 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: Stefan Kanthak <stefan.kanthak@...go.de>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DLL hijacking POC (failed, see for yourself)

> 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.

Besides, I did ask for suggestions why my tests "failed".

> 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".

> 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
- loading from the wrong directory (CWD instead of base) - is wrong

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.

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.

Chris.

On Tue, Sep 14, 2010 at 11:15 PM, Stefan Kanthak
<stefan.kanthak@...go.de> wrote:
>
> Christian Sciberras wrote:
>
> > I wrote my own example POC.
>
> and failed to use it right!
>
> [...]
>
> > DHPOC\example\the-install-folder\
> > DHPOC\example\the-install-folder\dhpocApp.exe
> > DHPOC\example\the-install-folder\dhpocDll.dll
> > DHPOC\example\the-remote-folder
> > DHPOC\example\the-remote-folder\example.dhpoc
> > DHPOC\example\the-remote-folder\dhpocDll.dll
> >
> > While testing this, I noticed that the dll hijack exploit completely
> > failed my tests (on Windows 7 64bit).
>
> No, you failed the test!
> The "application directory" is ALWAYS the first one where both implicit
> (referenced in the binary) as well as explicit (via LoadLibrary())
> loading will search.
>
> Next time, do your homework first!
>
> 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/