| |||||||||||||||||||||
Date: Tue, 11 Feb 2003 08:57:42 -0500 From: Peter Huang <yinrong@rogers.com> To: bugtraq@securityfocus.com Subject: Followup: breakpoint the stack buffer overflow from executing maliciouscode like SQL Slammer worm Andrew McGill emailed me with the following comments: > This is a nice technique - however it is quite probable that a > jmp esp instruction can be found which is preceeded by an > innocuous instruction ( add bx,si ; jmp esp ... ) ... "quite > probable" in the above means I haven't actually looked. That was a very good question. Actually, I thought about the above more after my original post and came up with the following. The basic concept is ⌠there will be no void parameter function call or traditional WINAPI call■. For a void parameter function: 1. Call SomeVoidFunction() The compiler will generate this code such as: Push 0 Call SomeVoidFunction Add esp, 4 ; can be pop ecx etc. In the called function SomeVoidFunction itself, it is coded as: Add [esp+4], 0cch ret 2. Call SomeApiFunction(par1, par2 .. ) The compiler will generate this code such as: Push 0 Push .. Push par2 Push par1 Call SomeApiFunction ; PASCAL-style Add esp, 4 ; can be pop ecx, etc In the called function SomeApiFunction itself, it is coded as: Mov [esp+4+X << 2], 0cch ; where x is the parameter number Ret X << 2 3. For a normal C function with parameter, it is still coded as: add [esp+4], 0cch ret This method will work to call old existing libraries because it just wastes a few cycles with ⌠push 0■ and ⌠add esp, 4■. However, the 0CCh-inserted libraries or object files will not work with old call methods (without extra push 0 and pop). Best regards Peter Huang For the latest update on this thread, pls visit http://members.rogers.com/yinrong/articles/BreakpointBufferFlow.htm
| |||||||||||||||||||||
|