On Tue, 16 Nov 1999, Jeremy Kothe wrote: > Just a general note concerning Windows overflows - most (if not all) of the > publicly available exploits I have seen floating around are still using > hard-coded addresses for system calls. > > I thought people might want to know that it is possible (and, indeed quite > easy) to get the addresses of system functions in a system independant way. > > The technique is simple - all windows processes are launched (called) from > Kernel32.dll originally, so at the TOP of the stack (give or take a DWORD, > depending on launch environment) there is a pointer to code inside > kernel32.dll. > > Given that the top of the stack is stored at fs:4, it is easy to scan from > the top of the stack, looking for kernel32.dll's pe header. > > Using an SEH block to skip over incorrect addresses on the stack, we > can locate and lookup whatever functions we want from Kernel32 (and from > there to any other .dll) Most of the time, as you will be targetting a specific version of a program - it simply isn't worth the effort. Using static links to GetProcAddress and LoadLibrary of the targets executable saves you the trouble and the extra bytes. I have used a similar technique once while doing a penetration test. The system was using a vulnerable cgi, unfortunately the cgi had multiple versions - and no hint was given to what version the remote system was running. In this case, the technique is a good one.. because you can afford to 'hit and miss' - only having to supply different RET addresses and some slight buffer manipulation definitely saves time and hassle. I may release that particular exploit to demonstrate the technique used.. I think the reason there haven't been any made publicly available is a good 3/4 of the time there just isn't a lot of point making use of the method. Cheers, dark spyrit http://www.beavuh.org - bend over and pray.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:13:16 PDT