Date: Thu, 16 Sep 2010 01:19:58 +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:

>> Yes. Once again: get your homework done!
>>
>>> http://www.codeproject.com/KB/DLL/dynamicdllloading.aspx
>>
>> That's a double DYNAMIC there!
> 
> Did you even bother to read the article? The very first paragraph
> states the difference between the two.
> 
> Oh, and for the records, you can't statically link to dll files. At
> least, not in the way you're imagining.

You should start to read what I wrote in
<34A088424C7D499F988D1ADCA645BA8D@...alhost>:

| Static linking occurs when the linker builds a binary (this might be a
| DLL.-) using *.OBJ and *.LIB.

> Static linking (in your case) only works for object files (.o or .lib).

I wrote that already.

>> 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!
> 
> Forfuckssake where did this point come from?

Your completely superfluous trip to codeproject.com!

>> Nobody can load a DLL that does not exist!
> 
> Wow what genius! The hell with that. It's the practice that is wrong.
> As the saying goes, one shouldn't cry over spilled milk;
> attempting to load a non-existent is asking for trouble.
> 
> Oh, and by the way. Looks like MS just broke your little fact...
> ...they've been loading an nonexistent dll via ACROS' POC (via wab.exe).

Bloody wrong: the .DLL accompanies the *.VCF in the share.

>> 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!
> 
> And they are right. You shouldn't be doing the OS's work.
> 
>> Hint #2: loading a DLL does not mean to run any code from this DLL!
> 
> But it is still loading the library into memory.

That's what I expect when loading a DLL.

> From there on, perhaps, some buffer overflow exploit would escalate the issue.

Which issue? Ever heard of Occams Razor?!

> At which point we all go critical over the damn crap just like you're
> doing right now.

Why? You wrote that your self-written POC failed!
ACROS' POC but works. Who's wrong?

>> 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)?
> 
> Because that is the damn point of the function, to tell us what the
> hell the loader is doing!!

Which function then tells me what your function is doing?
LoadLibrary*() IS documented, and its rather well documented.
There's no need to reprogram it. Just use it. And check its return code!

>> Why should someone with a sane mind let a program (or the OS) search
>> a DLL twice? Just to waste performance?
> 
> Why search? A simple CreateFile() (aka FileExists in winapi) over the
> cached path would suffice.

Which cached path? KISS!
Remember: for DLL hijacking to work the input to LoadLibrary() needs to
be a simple filename or a relative pathname.

> Perhaps returning this cached path would completely solve the issue.

Perhaps. The Win32 API but does not provide such a function!

>> 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.
> 
> That is NOT true.

OF COURSE THIS IS TRUE!

> I don't know if it was, perhaps in the Win95 era,
> but it most certainly is not there today.

%PATH% is ALWAYS equivalent to .;%PATH%

> That was what my POC proved. Did you read the full article? I
> mentioned cases where the bad dll (in CWD) would not be loaded (and an
> error followed instead).
> 
>> Consult MSDN on the DLL load order.
> 
> I don't have to. If you spared one moment from trolling, you might
> have noticed me dumping a list from ProcessMonitor...which clearly
> shows what the dll loading order is.
> 
>> BTW: Windows' "base directory" is MSFTs notion of $HOME.
>> Use the right terms/words, PLEASE.
> 
> Mind not putting words in my mouth? As far as definition goes, a "base
> directory" is where the source program started from...

Wrong. That's the "application directory".

> that could be a docroot of an index.php file

Wrong again. *.PHP is no executable file format, but associated to an
application. See CMD.EXE /K ASSOC .PHP and then FTYPE with the output
of the ASSOC. 

> or C:\Windows for notepad.exe.
> No one said anything about Windows!

ACROS showed a POC for Windows' address book using a *.VCF and a .DLL
built for Windows.

>> 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.
> 
> Tell THAT to ACROS and their POC!
> Why should I care for existence of a certain functionality if it is
> not by default (and if doesn't relate to the issue at all)?

You obviously need some courses in Windows basics.
Just turn SAFER on, WITH logging, and check the log!

>> Yes kiddo. I wrote DLLs for mainframes, 35 years ago. I wrote DLLs for
>> UNIX, 30 years ago.
> 
> Ahem? UNIX doesn't have "dlls", they're "shared objects".

No, UNIX has shared libraries.

> Speaking of which, coding for practically dead devices doesn't mean
> you have any real knowledge of newer ones.
> Just as I wouldn't expect a simple assembly programmer to
> automatically debug through and understand a .NET-based application.
> 
> Before you start shouting "they do the same thing" just consider how
> this issue (obviously) doesn't relate to those systems at all.
> 
> By the way, oldie, get a darn life an stop accusing people of what
> they didn't do.
> This whole discussion started from your saying "I did it all
> wrong"...perhaps, you ought to look into what I was really doing "all
> wrong".
> 
> Since this seems to be a complete waste of my time, don't expect any replies.
> I don't usually do this to conversations but really, this dll hijack
> crap already took enough of my time,
> let alone (attempting) to educate a fellow Seasoned UNIX Expert over
> Windows dynamics (which I'm failing anyway).

Get a life, kid!

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