Monday, November 22, 2010

MS10-054 Microsoft Windows SRV.SYS SrvSmbQueryFsInformation Pool Overflow DoS

Another SMB protocol vulnerability that catch my eye these few days - MS10-054 Microsoft Windows SRV.SYS SrvSmbQueryFsInformation Pool Overflow DoS. My curiosity as the same : How it work?

This vulnerability has first discovered Laurent GaffiƩ in early 2010. He also discovered the issue in ms10-020 vulnerability previously. Summary from the advisory :

"A vulnerability in the Windows kernel can be triggered via SMB in Microsoft
Windows versions ranging from Windows 2000 through to Windows 7. This vulnerability allows an attacker to trigger a kernel pool corruption by sending a specially crafted SMB_COM_TRANSACTION2 request.Successful exploitation of this issue may result in remote code execution with kernel privileges, while failed attempts will result in a Denial of Service condition. Microsoft haspublished a patch to resolve the issue"

What is SMB_COM_TRANSACTION2 ?
From [MS-CIFS].pdf, SMB_COM_TRANSACTION2 subcommands provide support for a richer set of server-side file system semantics. The "Trans2 subcommands", as they are called, allow clients to set and retrieve Extended Attribute key/value pairs, make use of long file names (longer than the original 8.3 format names), and perform directory searches, among other tasks.

The subcommand can be find in http://manubatbat.free.fr/doc/smb/6.2.htm

The original SMB_COM_TRANSACTION2 request is in this format :

SMB_Parameters
{
UCHAR WordCount;
Words
{
USHORT TotalParameterCount;
USHORT TotalDataCount;
USHORT MaxParameterCount;
USHORT MaxDataCount;
UCHAR MaxSetupCount;
UCHAR Reserved1;
USHORT Flags;
ULONG Timeout;
USHORT Reserved2;
USHORT ParameterCount;
USHORT ParameterOffset;
USHORT DataCount;
USHORT DataOffset;
UCHAR SetupCount;
UCHAR Reserved3;
USHORT Setup[SetupCount];
}
}
SMB_Data
{
USHORT ByteCount;
Bytes
{
SMB_STRING Name;
UCHAR Pad1[];
UCHAR Trans2_Parameters[ParameterCount];
UCHAR Pad2[];
UCHAR Trans2_Data[DataCount];
}
}

How MS10-054 works?
The culprit is the MaxDataCount field! It indicates the maximum number of data bytes that the client will accept in the transaction reply. Windows will allocate a pool chunk with the MaxDataCount size without any sanity check. By allocating ZERO size of pool chunk, it could be a trouble if freeing the memory chunk.

PoC can be found in the full disclosure adviosry http://seclists.org/fulldisclosure/2010/Aug/122 . I have try to test the PoC and it work with the target machine is in "WORKGROUP" domain and has a user namey "Y0" (0 is the zero).

C:\Python26>python.exe test.py 192.168.56.101 C
[+]Negotiate Protocol Request sent
[+]Session Query sent

C:\Python26>python.exe test.py 192.168.56.101 C
[+]Negotiate Protocol Request sent
[+]Session Query sent
[+]Malformed Trans2 packet sent
[+]The target should be down now

C:\Python26>

And the WinXP VM freezee...

For the PoC packet, we can clearly see the culprint "MaxDataCount = 0".

After all, the working exploit has included in metasploit modules/auxiliary/dos/windows/smb/ms10_054_queryfs_pool_overflow.rb

No comments:

Post a Comment