Analysis of MS11-011 Vulnerability

QEver

I have long wanted to analyze the legendary elders vulnerabilities, but I have never had time to analyze all kinds of things due to school start. I have spent the past two days analyzing the vulnerabilities, I was planning to study the use of code and patches, but now I have to give up. Now I am posting my own analysis process. The reverse and Chinese capabilities are not good, so I cannot describe them clearly. Please forgive me, you are also welcome to shoot bricks, but please be as gentle as possible!

The following content is for your personal understanding and cannot guarantee its correctness. It is for your reference only !!!

Test environment: Windows 7
Test Tool: VMWare + Windbg + IDA

First, download the vulnerability exploitation program and test it on the virtual machine. The program can run normally:

Code:
C:> whoami
Q-testqever

C:> poc

C:> whoami
Nt authoritysystem
The following describes the causes of the vulnerability.
To reduce the workload, we should try to determine the exact location of the vulnerability generation. Here, we use the method of adding 0xcc to the shellcode start position of the poc source code, corresponding to the "int 3" command, in this way, the shellcode will be disconnected immediately and then analyzed.

The modification process is not nonsense. You can directly run the modified program. When windbg is disconnected, you can view the call stack, but find that the call stack is damaged.

Code:
Kd> k
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00000000 00000000 0x3d0000
In this case, you can roughly estimate the error location by analyzing the current stack. Of course, there is also a better method. Considering that the program can be normally executed, the shellcode will definitely return the call location after running, so the shellcode will be disconnected at the return location, view the stack after the operation is disconnected again.

Code:
Kd> k
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
92639d14 994bb8d0 0x3d0096
92639d28 83c7f42a win32k! GreEnableEUDC + 0x7c
92639d28 772964f4 nt! KiFastCallEntry + 0x12a
When you see the above information and combine the vulnerability trigger code in the poc source code, you can determine that the problem occurs in win32k! The GreEnableEUDC function is used to analyze the cause of the vulnerability!

To reduce the workload, a stupid method is used here. multiple attempts are made to accurately identify the cause and location of the error. The process is as follows:
In win32k! Run the modified program at the breakpoint at GreEnableEUDC and track it in one step until the "int 3" command in shellcode is triggered. After multiple attempts, you can determine the following call information:

Code:
Win32k! GreEnableEUDC + 0x77: call win32k! Buildandloadw.fontroutine + 0xeb
Win32k! Buildandloadw.fontroutine + 0x19d: call win32k! BAppendSysDirectory + 0x209
Win32k! BAppendSysDirectory + 0x334: ret 8 // error!
That is, when you call win32k! After the bAppendSysDirectory + 0x209 function is returned, it jumps into the shellcode. When it returns, it can be found that the return address is modified, that is, the stack space is modified during the function running, that is, the stack overflow.
Based on the information on the Internet, the entire vulnerability generation process can be determined after multiple attempts:

Code:
Nt! KiFastCallEntry + 0x128: call ebx (win32k! GreEnableEUDC)
Win32k! GreEnableEUDC + 0x77: call win32k! Buildandloadw.fontroutine + 0xeb
Win32k! Buildandloadw.fontroutine + 0x19d: call win32k! BAppendSysDirectory + 0x209
Win32k! BAppendSysDirectory + 0x2de: call dword ptr [win32k! _ Imp _ RtlQueryRegistryValues (9972f104)]
Nt! RtlQueryRegistryValues + 0x318: call nt! RtlpCallQueryRegistryRoutine (83e2ab81)
Nt! RtlpCallQueryRegistryRoutine + 0x290: call nt! RtlpQueryRegistryDirect (83e33997)
Nt! RtlpQueryRegistryDirect + 3D: call nt! Memcpy (83c797a0) // Overflow
Win32k! BAppendSysDirectory + 0x334: ret 8 // error!
As long as the behavior of the functions listed above is analyzed, the cause of the vulnerability should be determined.

Next, let's analyze the above functions one by one. In the actual analysis process, Windbg dynamic debugging and IDA static analysis are performed at the same time. Here, we only analyze Windbg code for ease of writing.

For win32k! GreEnableEUDC involves some variables that do not know what they mean, but does not affect the analysis process.

Code:
Win32k! GreEnableEUDC + 0x37:
9956b88b 33f6 xor esi, esi // esi erasing
9956b88d 46 inc esi // esi = 1
......
Win32k! GreEnableEUDC + 0x75:
9956b8c9 56 push esi // parameter pressure Stack
9956b8ca 56 push esi // parameter pressure Stack
9956b8cb e8b8faffff call win32k! Buildandloadw.fontroutine + 0xeb (9956b388)
Here, we will simply mention that the call parameters are all 1. After all, the cause of the vulnerability is not this.
This function should correspond to EnableEUDC (TRUE) in the poc source code. In a sentence, EUDC will not be explained, because no good Chinese information is found, and Microsoft's introduction is attached:
Aspx "> http://msdn.microsoft.com/zh-cn/library/ms900737.aspx
According to the previous analysis, follow win32k! Buildandloadw.fontroutine + 0xeb function, so the two parameters of this function are listed here, both of which are 1.

Next, let's take a look at the buildandloadw.fontroutine + 0xeb function, which does not have any important content, but still lists parameters and call statements.

Code:
995cb393 be08020000 mov esi, 208 h
995cb398 56 push esi
995cb399 8d4dfc lea ecx, [ebp-4]
995cb39c e8a6030000 call win32k! MALLOCOBJ: MALLOCOBJ (995cb747) // generate a MALLOCOBJ object
......
995cb3aa 8b5dfc mov ebx, dword ptr [ebp-4]
......
995cb434 6804010000 push 104 h
995cb439 53 push ebx
995cb43a e8a0050000 call win32k! BAppendSysDirectory + 0x209 (995cb9df)
Win32k! The two parameters of the bAppendSysDirectory + 0x209 function are MALLOCOBJ object pointer and 0x104.
About win32k! MALLOCOBJ personally feels like a string class. During the vulnerability analysis process, this object also plays the role of a string and records the string information at the starting position of the memory.

The following win32k! The bAppendSysDirectory + 0x209 function is critical, and the final error is also in this function. first look at the Code:

Code:
Win32k! BAppendSysDirectory + 0x209:
9955b9df 8bff mov edi, edi
9955b9e1 55 push ebp
9955b9e2 8bec mov ebp, esp
9955b9e4 83ec20 sub esp, 20 h
9955b9e7 53 push ebx
9955b9e8 56 push esi
9955b9e9 57 push edi
9955b9ea be08020000 mov esi, 208 h
9955b9ef 56 push esi
9955b9f0 8d4df4 lea ecx, [ebp-0Ch] // ebp-0Ch is MALLOCOBJ object pointer
9955b9f3 e84ffdffff call win32k! MALLOCOBJ: MALLOCOBJ (9955b747)
9955b9f8 56 & nb