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: <AANLkTikZdU0K6rAw9hrbnnn=cfJ=te79Sdh73jLq5vOk@mail.gmail.com>
Date: Wed, 15 Sep 2010 18:05:46 +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)

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

Oh really?

http://www.codeproject.com/KB/DLL/dynamicdllloading.aspx

Note that I never mentioned "linking" above. Also note that the first
sample code does not mention the need of any object files.

> Another misconception: nonexistent DLLs can and will NEVER be loaded.

How can you say something might but will never do something?
It is either "might" or "won't".

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

Any reasonable framework out there, provides the developer an "exists"
functionality.
Surely I don't have to run an exeuctable to know that the file exists?
Likewise, such functionality should exist to tell me which dll would
be loaded beforehand.

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

Didn't you say loading from CWD comes after loading from the
application directory?
I did say what such a wrong directory would be: loading from the
current working directory vs loading from the base directory.
If you don't know the difference or implications, just search for the
phrase, not attempt to ask abstract questions.

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

What are we doing again here? Oh right. Because as far as SAFER goes,
it DOES NOT WORK. At least not by default.

Stefan, may I ask how much experience do you have with dlls? I don't
consider being an expert in this area, but I wrote such libraries for
both windows, osx and linux.
In the case of windows dlls, I can assure you that I've noticed some
of the neatest tricks around, which as far as FD goes, have never even
been discussed (as far as I know), for some reason.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/