Tutorial: SEH Based Exploits and the Development Process

[Nytro]

Tutorial: SEH Based Exploits and the Development Process

Tutorial by Mark Nicholls AKA n1p

The intent of this exploit tutorial is to educate the reader on the use and understanding of vulnerabilities and exploit development. This will hopefully enable readers to gain a better understanding of the use of exploitation tools and what goes on underneath to more accurately assess the risk of discovered vulnerabilities in a computer environment. It is important for security consultants and ethical hackers to understand how buffer overflows actually work, as having such knowledge will improve penetration testing capabilities. It will also give you the tools to more accurately assess the risk of vulnerabilities and develop effective countermeasures for exploits doing the rounds in the wild.

With this in, I am going to focus exclusively on the practical skills needed to exploit Structured Exception Handler buffer overflows. I won't go into too much detail regarding the theory of how they work, or how buffer overflows can be discovered. There are many other resources available on this subject, and I encourage you to research this further

Warning! Please note that this tutorial is intended for educational purposes only, and skills gained here should NOT be used to attack any system for which you don't have permission to access. It is illegal.

Brief Intro to Structured Exception Handlers (SEH)

An exception handler is a piece of code that is written inside an application with the purpose of dealing with cleanup activities when the application throws an exception error. A typical exception handler looks like this:

    try {

    line = console.readLine();
    } catch {

    (Exception e) {
    console.printLine("Error: " + e.message());
               }
    }

When no exception handlers have been coded by a developer, there is a default Structured Exception Handler that is used to handle exceptions within Windows programs. Every process has an OS supplied SEH, and when a Windows program has an exception that it cannot handle itself, control is passed to a SEH address that has code that can be used to show a dialog box explaining that the program has crashed. As seen below:

About Structured Exception Handling (Windows)

A Crash Course on theDepths of Win32 Structured Exception Handling, MSJ January 1997

This default handler is seen at 0xFFFFFF and viewable in a debugger as such in the Stack window below. This is the end of the Stack Chain and should always be hit if the program cannot successfully handle crashes.

The SEH chain is essentially a linked list that is laid out in a structure similar to the chain below with the default OS handler at the end.

Each code block has its own stack frame, and the pointer to the exception handler is part of this stack frame. Information about the exception handler is stored in an exception_registration structure on the stack. Each record then has the following info:

• A pointer to the next SEH record

• Pointer to address of the exception handler (SE Handler)

Ok, that’s enough theory. References are provided at the end for further reading and learning. On to the practical stuff...

Tutorial:

http://www.ethicalhacker.net/content/view/309/2/