Date: Fri, 17 Sep 2010 11:08:57 +0200
From: Christian Sciberras <uuf6429@...il.com>
To: huj huj huj <datskihuj@...il.com>
Cc: Stefan Kanthak <stefan.kanthak@...go.de>, full-disclosure@...ts.grok.org.uk
Subject: Re: DLL hijacking POC (failed, see for yourself)

We did, it's number is 253 ... $000000FD.




On Fri, Sep 17, 2010 at 11:07 AM, huj huj huj <datskihuj@...il.com> wrote:
> hey funboys! get a room!
>
> 2010/9/16 Stefan Kanthak <stefan.kanthak@...go.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@...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/
>
>

_______________________________________________
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