Well, SEHOP, or Structured Exception Handler Overwrite Protection, is the most effective mitigation strategy that exists for SEH overwrites. There were previous attempts at creating mitigations for SEH overwrites, but they weren't always very effective. SEHOP is incredibly effective, and is one of the mitigations that is specifically enabled by EMET, and you're allowed to fine-tune control of SEHOP on a program-by-program basis. So to review real quickly, we talked about the SEH overwrite is overwriting these records that point to exception handlers that handle various error states within your running program. And by overwriting one of those and pointing it, pointing the records to code we control, and then intentionally creating one of those error states, we can redirect the execution of the entire program, before the stack cookie ever gets evaluated. Now what SEHOP does is it actually walks this chain of structured exception handlers. So the SEH records are set up in a linked list, so that each one contains a pointer to the next one that it should try if that one fails.
And when we do our overflow, this is the most important thing we have to overwrite, but to overwrite this, we have to overwrite the pointer to the next one in the chain anyways. It's also typically what we use to have more accurate control over where we're jumping into memory that we control. So what happens is, if this is the SEH record that we're overflowing right here, we are going to corrupt both of these values right here. What SEHOP is going to do is when the Structured Exception Handler routines are triggered, it's going to walk this chain from start to finish. So it's gonna look at the first exception handler record, and it's going to look at the pointer to the next SEH. And it's going to see is that a valid, is that a valid pointer in our memory space, and if so, it's going to go to it, and say, "Is this a valid SEH record here?" And then if it is, it goes to, it takes that pointer and it goes to the next one, and it walks the whole chain, the whole way down, once the structured exception handlers are triggered, and makes sure that every one of those Structured Exception Handler records is still a valid SEH record.
So what happens is if we overwrote this one in our buffer overflow here, and this is a pointer to our POP, POP, RET [inaudible 00:03:10] and this is an assembly instruction that is jumping either forwards or backwards in memory, to land into our shellcode, SEHOP's going to follow this pointer, it's gonna land here, and it's gonna look at that, it's gonna try and interpret it as an address, and when it tries to look at memory at that location, it's not going to point to this next SEH record, and it's going to say, "Whoa. This is a corrupted SEH...a corrupted Structured Exception Handler record. Something fishy is going on here. Stop execution right now." And that main thread that this is running in will exit.
Now if you're in a multithreaded program, like some kind of server, it means that it'll probably fail gracefully, and just stop running...processing whatever request you sent it, or if it's a single-threaded application, it may cause the entire application to just exit unexpectedly, and generate an error, which from an attacker's point of view, is actually even worse, because while it's disruptive to the victim, it also immediately sets up a red flag that something suspicious has happened here. When the program crashes and creates an error code, somebody is going to notice that and take a look at it. So SEHOP is by far the most effective mitigation strategy that you can use for preventing these SEH overwrites in your programs. And like I said before, Microsoft's exploit mitigation experience toolkit, or EMET, allows you to enable SEHOP on a program-by-program basis on your system, giving you fine-tuned control and mitigation against a lot of different buffer overflow attacks.
Thanks for joining us, and we'll see you next week.
