Message-ID: <8F1DD5F7F7054F15A3E53EE90264775C@localhost>
Date: Wed, 15 Sep 2010 22:25:51 +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:

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

Yes. Once again: get your homework done!

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

That's a double DYNAMIC there!

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

Why should I bother to do the work of the loader?
I reference the DLL export in my code and expect the loader to resolve
it. There is no need for fancy do-it-yourself DLL entry resolution!

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

Nobody can load a DLL that does not exist!

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

Why should I call or even write a routine which checks whether a DLL
exists instead of just calling the loader and let it search/load it?
Hint #1: this is exactly what MSFT advices NOT to do!
Hint #2: loading a DLL does not mean to run any code from this DLL!

Who guarantees that your self-written or the OS supplied search routine
will find the same DLL as the loader (just in case you do not use the
fully qualified pathname of the DLL)?

To quote <http://msdn.microsoft.com/en-us/library/aa365527.aspx>:

| The SearchPath function is not recommended as a method of locating
| a .dll file if the intended use of the output is in a call to the
| LoadLibrary function. This can result in locating the wrong .dll
| file because the search order of the SearchPath function differs
| from the search order used by the LoadLibrary function. If you need
| to locate and load a .dll file, use the LoadLibrary function.

To quote <http://msdn.microsoft.com/en-us/library/ms684175.aspx>

| Security Remarks
|
| Do not use the SearchPath function to retrieve a path to a DLL for a
| subsequent LoadLibrary call. The SearchPath function uses a different
| search order than LoadLibrary and it does not use safe process search
| mode unless this is explicitly enabled by calling SetSearchPathMode
| with BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Therefore, SearchPath is
| likely to first search the user's current working directory for the
| specified DLL. If an attacker has copied a malicious version of a DLL
| into the current working directory, the path retrieved by SearchPath
| will point to the malicious DLL, which LoadLibrary will then load.

Why should someone with a sane mind let a program (or the OS) search
a DLL twice? Just to waste performance?

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

For DLLs: always. For EXEs: it depends. Just read it in the MSDN!

Just in case that you misunderstood "from the very beginning" let me
rephrase it: from the earliest days of DOS/Windows CWD was in the PATH.

> I did say what such a wrong directory would be: loading from the
> current working directory vs loading from the base directory.

Consult MSDN on the DLL load order.
BTW: Windows' "base directory" is MSFTs notion of $HOME.
Use the right terms/words, PLEASE.

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

Can I assume that you tested it just like you failed to test your own
POC?
SAFER works quite well here (and there too) for about 7 years now.

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

Yes kiddo. I wrote DLLs for mainframes, 35 years ago. I wrote DLLs for
UNIX, 30 years ago.

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

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