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

[Christian Sciberras <uuf6429 () gmail com>]

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




On Fri, Sep 17, 2010 at 11:07 AM, huj huj huj <datskihuj () gmail com> wrote:
> 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/