Full Disclosure mailing list archives

Previous By Date Next
Previous By Thread Next

Re: DLL hijacking POC (failed, see for yourself)

From: huj huj huj <datskihuj () gmail com>
Date: Fri, 17 Sep 2010 11:07:16 +0200
hey funboys! get a room!

2010/9/16 Stefan Kanthak <stefan.kanthak () nexgo de>


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@localhost>:

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


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

Current thread: