Oracle 10 & amp; 11g exp.exe 0day Stack Overflow

Just now I was bored. I found an Oracle 11g database with a 0-day attack with a somewhat high impact (but low likleyhood. This vulnerability is resolved in the "file" field in the specified parameter file on the command line of the Oracle export utility. The EXPORT utility runs as privileged code. However, the vulnerability is technically exploited by imteresting.

So what is the situation? A special parameter file can cause a stack-based buffer overflow, allowing attackers to control the execution stream of the target application. Although this seems to be a relatively simple principle and is unlikely to be exploited, attacks can cause serious consequences. If attackers can persuade Oracle DBAs to use this malicious parameter file to issue an exit, they can gain a complete system administartors account compromise.
The structure of the file looks like this:
Indexes = n
Logstores results.txt
File = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. dmp
Our overflow application sends out the following command:
$ ORACLE_HOME \ BIN \ exp.exe system parfile = malicious_file.par
So, what about the debugger? Let's take a look:
 
 
Now we can see a lot of information. First, we did not actually touch all SEH chains, but in fact, we hit the EIP directly. What's interesting now... where are we going to jump? ESP is the only place to go. We have only two bytes of control on the stack. Interesting! So how many bytes do we need to skip very short? Fortunately, we only need two bytes! But before that we get a jump, let's get in ESP.
 
To reach ESP, I just use a JMP ESP USER32.DLL in Windows XP SP3. I set a break point, in "JMP ESP", and then press F9 to continue execution. Now, we need two skip bytes. I use a back JMP '\ XEB \ XF5 "(because we want to go up, because we end the stack in our string buffer ). I was surprised to see that \ XEB is a allowed character, because we are a file name overflow, so I expect strict ASCII character sets.
 
The jump is short, but if we want more bytes to operate, we must jump further ......
 
Using five bytes, we execute a long jump "\ xe9 \ X2A \ XFE \ XFF '. There must be 5 bytes. This hop only executes the total number. Once we calculate to jump to the top of our overflow string, we realized that we had about 500 bytes before we typed our previous instructions. This is a certain degree of restriction. Ideally, we want more shellcode space. In addition, due to the character limitations of this application (almost 100% ASCII), we will need more space if we encode it with our payload.
How can we bypass these restrictions? How can we execute the shellcode, which is very restricted in a specific character set?
After playing the application for a while, I noticed that in the instruction pointer we overwrite, our string buffer seems to have a large amount of space (about 1500 bytes) in the heap memory ).
 
Looking at the heap memory, we can see a large number of bytes. Here we can set up a final-stage shellcode. If we can have all our spaces in some way, we need to execute our shellcode. But how do we get there? Maybe we can include a specific four-byte string value, and we choose to execute the final shellcode address scan memory. This is the so-called hunter Skape, which is a small shell code. It searches for the memory of a 4-byte string and starts execution. Then it is found that a 4-byte string is written into an egg.
You can read corelanc0d3r.