Date: Thu, 16 Sep 2010 13:14:29 -0400
From: T Biehn <tbiehn@...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)

Shit man, I was keeping notes for my class in pedantry, can't you two keep
it going for a few more days?

-Travis

On Wed, Sep 15, 2010 at 7:19 PM, Stefan Kanthak <stefan.kanthak@...go.de>wrote:

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



-- 
FD1D E574 6CAB 2FAF 2921  F22E B8B7 9D0D 99FF A73C
http://pgp.mit.edu:11371/pks/lookup?search=tbiehn&op=index&fingerprint=on
http://pastebin.com/f6fd606da

Content of type "text/html" skipped

_______________________________________________
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