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.
