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 <[email protected]>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 > <34a088424c7d499f988d1adca645b...@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/ > -- 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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
