www.okc2600.com

[ri0t]

Ok so recently i have been working on a couple of Buffer Overflows where EIP is gained through smashing SEH so here is a quick mini primer on smashing SEH for fun and profit


So here is the short definition when a win32 program runs it sets on the stack and address of the SEH the program will jmp to this address if there is ever an exception that causes the program to die Thus the reason it is called the Standard Exception Handler.

So on occasion you will have a program that you can overflow the buffer thus overwriting data on the stack but and exception fires during the copy or something else in the data stream causes an exception causing the program to fire the SEH before you get code execution (thats overly simplified but you get the point) So what is a researcher to do? how bout overwrite the address that SEH is pointing to


So if we overwrite the buffer we will eventualy get to 2 address on the stack the first is the "Pointer to the Next SEH" and then the next address after that is the current SEH so coceptualy our buffer looks somewhat like this



<buffer space>
<Pointer to Next SEH>
<SEH>
<more buffer space>


so if we send a buffer and fill the top buffer space with A's then set the Pointer to the Next SEH to BBBB set the SEH to CCCC and the second buffer space to DDDD our buffer will look something like this (again this is just an example)

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDDDDDDDDDDD


now remember this is just an example in the real world the buffers hopefully will be much bigger

so when the exception fires what you will see is eip set to CCCC and then 2 addresses down from EBP (stack base pointer) you will see a address that contains this


BBBBCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD


now thats kinda interesting thats our buffer but how do we get to it?

Bring on the pop pop ret . If we can set the SEH to an opcode that contains a Pop Pop Ret when it fires it should pop 2 addresses off the stack and return into our buffer. ok so now we can get into the buffer but how do we get to shellcode from here? after all the buffer doesnt just contain our shellcode of DDDDDD it also contains BBBB and CCCC so what are we to do? Well up until this point we havnt used the Pointer To the Next SEH address for anything (the BBBB space) so what we do is we set BBBB to \xEB\x06\xFF\xFF what is \xEB\x06? in assembly it is Jmp Short 6 bytes so when we pop pop ret into this space the execution flow will hit this jump over our CCCC return address directly into our DDDDDDDD shellcode YaY!!!!

so now we have code execution by Busting the SEH on win32 programs


Some things to think about....

The buffer space after the return address may be to small for a full payload which means we may have to use a staged payload that jumps back into our main buffer


In windows XP sp2 microsoft introduced SafeSEH which limits where the SEH can point to. this can be overcome by pointing back into the binary itself for a pop pop ret provided the binary hasnt also been compiled with /SafeSEH




Just some things to think about and mabey get the brain juices flowing



ri0t
_________________
EIP=0x41414141


ri0t

[ferralis]

Additional things to think about...

Brain juices pumping... Thanks, Ri0t. I'm not sure if it was your article or the fact that I was standing on the juice hose. (pause for image to manifest)

So this type of exploit would work beautifully for all compiled languages that have built-in exception handling. At this point, I think that is limited to ass'y and C++. Oh, and maybe Ada and Forth... but seriously now...

Is my thinking right on that? Even limiting to just C++ apps this is an awesome tactic.

.Net and Java (and Python, Perl, Ruby, etc) all "compile" to bytecode- basically shorthand for the interpreter to read. I'm beginning to wonder, though, if you knew the interpreter well enough, if you couldn't introduce some happy nonsense into SEH... *eg*
_________________
Burn the box.

[ri0t]

Yes i could see this working for other languages provided there is a way to write arbitrary data to the stack. the reason we are able to do this in C++ compiled programs is normally due to a lack of bounds checking resulting in a buffer overflow. but provided there is some method to allow us to write data to the stack then yeah you could do something like this. also just as a point the SEH handlers in windows are usually well after your standard cpu registers in the stack so for instance say there is a overflow in a product but you only have say 12 bytes of buffer space that isn't much space to do anything with but if you say throw 3000 bytes at it you have a chance to overwrite the SEH handler and you can then use the technique described above . like most things in a computer system there are lots of ways to do something this is just another cool way to get code execution flow.
_________________
EIP=0x41414141


ri0t

[Saint_Patrick]

For the 1337 of you, this is not news. Luckily, a lot of you suck

I was working a SEH from 2000 Server up through XP SP2. As I was doing this I had a couple of issues as the patches rolled, getting my opcodes to hit though I knew they were correctly addressed. Suspecting SafeSEH as the culprit, but not knowing for sure.

For the past couple of weeks I had been using Immunity Debugger, which is basically Olly on crack. I'd go and do the ole search for instruction sequence, find a pop pop ret in a executable module, try it...fail...move on. Hoping to get lucky.

So here's the deal. In the '<imdbg dir>/PyCommands' there lives a host of scripts for doing various things. One of which is called safeseh.py. These scripts can be called from the in UI debugger command line. Calling !safeseh, will give you a sweet list of the modules that have been SafeSEH'd as well as an even more emphatic listing in the session log. No more guess work or manual monkeying.

For those showing Olly the love, a functionally similar plugin (OllySSEH) exists and can be downloaded from OpenRCE.org.

This is cool when using opcodes from dlls that might be hit and miss SafeSEH.
_________________
"I suck at internet."

[ri0t]

Hell yeah bro that is bad ass!!!!!!!!!!!
_________________
EIP=0x41414141


ri0t

[Saint_Patrick]

Recent post by Peter Van Eeckhoutte @ http://www.offensive-security.com/blog/vulndev/quickzip-stack-bof-0day-a-box-of-chocolates/ contains a detailed walkthrough of an SEH exploit (some of the issues encountered go beyond straight SEH).

This article is also worth mentioning for it's demonstration of using the !pvefindaddr tool. Definitely some niceties worth making use of.
_________________
"I suck at internet."