CVE-2010-0017 Technic Analysis

In this report I will analyze the procedure of a vulnerability of SMB protocol implemented in Microsoft. As it is not a secret one, you may find more details on the Internet.

Make a comment if you have any idea. SHARE IS ENCOURAGED.

Overview

By sending a malformed “Negotiate Protocol Response” packet, it may cause the SMB Client to trigger an overflow in kernel pool. A successful exploitation can result in a remote code execution. Besides, the attacker must convince the client to send a “Negotiate Protocol Request” to server.

Technical Details

0x01 Critical Parameter

According to some previous knowledge, we know that when a SMB server gets a “Negotiate Protocol Request” packet, it will send back a response to the client with some parameters as

“Word Count”, ”Dialect Index”, …… ,”Max Buffer Size”, etc.

The Parameter “Max Buffer Size” is defined in MSDN here

(http://msdn.microsoft.com/en-us/library/cc246326.aspx). It represents that the buffer size to send and receive SMB messages in the server. The max buffer size of clients to send SMB messages to the server depends on this value. The size is from the beginning of the SMB header to the end of the packet.

0x02 Procedure

In this part, I will show you how the parameter triggers the vulnerability.

Let’s take a look at the stack trace when the client crashes: 

Figure 1. Stack Trace

As it shows, we infer the pool is corrupt according to rdbss!_RxFreePool when it caused a bug check.

So, the entire process is :

The client firstly read the “MaxBufferSize” from the response packet sent by the server. Then it added 0x80 to that value as a final size to allocate a paged pool in memory.

Figure 2. Memory Allocation

Figure 3. Runtime Parameters

When the allocation succeeded, it returned the beginning of the pool address to EAX as below shows:

Figure 4. Returned Address

Let’s take a look at the pool allocated.

Figure 5.Pool information

When the allocation was done, following instructions initialized the memory with zero by obtaining the MaxBufferSize from ESI+138h.

Figure 6.Initialize the memory

When the program ran to 0xb2c73258, instruction here caused the overflow.

Figure 7. Overflow

We use !pool to see some information about this chunk

Figure 8. Pool Information

It is obvious that command at 0xb2c7325c overwrited the size of the next pool which caused a bug check when the program called mrxsmb!_RxFreePool to free the corrupt pool.

Figure 9 . Bug Check

0x03 Version information

Figure 10. Version