Date: Wed, 15 Sep 2010 23:33:07 +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)

> 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.
Static linking (in your case) only works for object files (.o or .lib).

Dlls are inherently dynamic. Which is why they can be *loaded* both
*statically* and *dynamically*.
You can call that "implicit" vs "explicit" all you want, but the fact
remains that one is static and the other is not.

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

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

> 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.
>>From there on, perhaps, some buffer overflow exploit would escalate the issue.
At which point we all go critical over the damn crap just like you're
doing right now.

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

> 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.
Perhaps returning this cached path would completely solve the issue.

> 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. I don't know if it was, perhaps in the Win95 era,
but it most certainly is not there today.
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...
that could be a docroot of an index.php file or C:\Windows for notepad.exe.
No one said anything about 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)?

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

_______________________________________________
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