On 18th Jan 2011, somebody named “h1ch4m” reported a stack based overflow vulnerability in “PDF All to mp3 converter” via exploit-db (Exploits Database by Offensive Security
). This vulnerability can be exploited by giving a malformed “.wav” file to the application. When i was checking the software on 29th jan 2011, i also found that it was also vulnerable to SEH overflow vulnerability, so i decided to write an exploit for the SEH overflow and submit to exploit-db (community based database of exploit and also great resource for penetration testers and vulnerability researchers). The SEH overflow exploit which i wrote can be found at “http://www.exploit-db.com/exploits/16073/”
. Before i get into explaining how to exploit the SEH overflow exploit in “PDF All to mp3 converter”, i will explain some of the basics required to understand SEH overflow exploit.
What are exception handlers?
An exception handler is a piece of code that is written inside an application to deal with the exception thrown by the application.
Windows has a default SEH (Structured Exception Handler) which will catch exceptions. If Windows catches an exception, you’ll see a “xxx has encountered a problem and needs to close” popup. This is often the result of the default handler kicking in.
Whenever an exception occurs in an application and when no exception handlers are used, or when exception handler is not available to process the exception, the windows SEH (structured exception handler) will be used. So whenever an exception occurs, the application gets a chance to catch the exception and do something with it. if no exception handler is defined in the application, the OS catches the exception and shows the pop up (asking you to send the error report to Microsoft).
In order for the application to be able to go the exception handler code, the pointer(address) of the exception handler code is saved on the stack. The information about all the exception handlers for an application is stored in an exception_registration structure (SEH chain) on the stack.
This structure which is also called “SEH record” is 8bytes and has two 4 byte elements:
a) Pointer to the next seh record, in case the current handler is not able to handle the exception.
b) A pointer to the actual code of the exception handler also called “SE handler”.
The structure of the SEH chain on the stack is shown below:
Uploaded with ImageShack.us
So how does the exception handler work.
When a program is executed and when the process is created, the pointer to the top of the SEH chain (the head of the seh chain) is placed at the top of the main data block of the process. When an exception occurs , windows ntdll.dll retrives the head of the seh chain (which is placed at the top of the main data block), walks through the list and tries to find the suitable handler. If no handler is found the default win32 handler will be used (which is at the bottom of the stack, the one after FFFFFFFF).
Protections mechanisms to stop SEH exploit
a) XOR protection
Since Windows XP SP1, before the exception handler is called, all registers are XORed with each other, making them all point to 0×00000000, which complicates exploit building. That means that you may see that one or more registers point at your payload at the first chance exception (before control is passed to exception handler), but when the Exception Handler kicks in, these registers are cleared again (so you cannot jump to them directly in order to execute your shellcode)
Some additional protection was added to compilers, to stop the a SEH overwrites. This protection mechanism is active for all dll’s or exe’s that are compiled with /safeSEH
Steps to follow to write seh exploit
In order to write an SEH overlfow exploit, these are the steps to follow:
a) Cause an exception, so that SEH handler kicks in.
b) Overwrite the SE handler on the stack with a pointer to the instruction that will bring you back to the next seh and execute jumpcode(the address of the POP POP RET instruction), this will put the address of top of the seh chain (pointer to the next seh record) on to eip, making it execute what ever is in that location.
c) We put some jumpcode inside the next seh, so that it jumps to the shellcode (which is right after the SE handler).
d) We place shellcode directly after the SE handler.
This was about the basics required to understand SEH overflow Now lets get into the fun part of exploiting the SEH vulnerability in the software.
Continued in Part2 (http://www.garage4hackers.com/blogs/...poc-part-2-238