Re: static dll's for windows buffer overflows

[dullien () gmx de]

Hey Franklin,

FD> Windows buffer overflows almost always require knowledge of offsets in
FD> dll's.  Even if rva is used, usually one offset is still known, to jmp to 
FD> where the code is (e.g., let's say the shellcode is pointed to by eax, we 
FD> need to know the offset of somewhere to jmp eax).  Which dll's are the most 
FD> static?  For the jmp instruction, we can use any dll, as long as it has 
FD> those bytes (i.e., we are not limited to kernel, user, and gdi).  Which 
FD> dll's are the best to use, and why?

There are of course other ways to attack the problem. If you happen to
know the exact version number of the application you're attacking, it
might be wise to use DLLs belonging to that application as they can be
version-fingerprinted remotely (e.g. Netscape Enterprise 3.6 SP2 is
announced in the banner so you know pretty well what host you're
attacking). Under NT, DLL's (especially system DLL's) can vary quite a
bit depending on SP, hotfix number and even language installed.

FD> (BTW, I would like to suggest that the term "buffer overflow" be replaced 
FD> with the term "memory overwrite," as there are many forms besides buffer 
FD> overflow, such as format string, malloc (0) mangling, etc. )

And especially with these new breeds of attacks more reliable ways of
exploiting them (especially under NT) seem to become available.
http://www.blackhat.com/html/bh-europe-01/bh-europe-01-speakers.html
Halvar Flake's speech blabber looks reasonably interesting in relation
to this.

Cheers,
Thomas Dullien