Message-ID: <60828CFFDBEBA946AC54D9293505E84DC74DDEC3@sssydmail01.stratsec.local>
Date: Wed, 10 Feb 2010 09:38:44 +1100
From: stratsec Research <research@...atsec.net>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: stratsec Security Advisory SS-2010-003 - Microsoft SMB Client Pool
 Overflow 

===============================================================================
Stratsec Security Advisory: SS-2010-003
===============================================================================

Title:           Microsoft SMB Client Pool Overflow (MS10-006)
Version:         1.0
Issue type:      Pool overflow
Affected vendor: Microsoft
Release date:    09/02/2010
Discovered by:   Laurent Gaffié
Advisory by:     Laurent Gaffié, Renaud Feil
Issue status:    Patch available

===============================================================================

Summary
-------

A vulnerability exists in the Microsoft SMB client which allows an attacker to
trigger a kernel pool memory corruption by sending a specific 
'Negotiate Protocol' response.

Successful exploitation of this issue may result in remote code execution with
kernel privileges. Failed attempts may result in a remote denial of service.

Description
-----------

Server Message Block (SMB), also known as Common Internet File System (CIFS) 
acts as an application-layer protocol to provide shared access to files, 
printers and Inter-Process-Communication (IPC). It is also a transport for
Distributed Computing Environment / Remote Procedure Call (DCE/RPC) operations.

When initializing an SMB communication the client sends a 'Negotiate Protocol'
packet to negotiate the dialect that will be used for further communication.
The server
response will contain the following structure:

uchar  WordCount;           /* must be 0x11 (17) */
ushort DialectIndex;        /* selected dialect */
uchar  SecurityMode;        /* security flags */
ushort MaxMpxCount;         /* maximum pending multiplexed requests supported*/
ushort MaxNumberVCs;        /* maximum virtual connections */
ulong  MaxBufferSize;       /* maximum SMB message size */
ulong  MaxRawSize;          /* maximum raw buffer size */
ulong  SessionKey;          /* unique session identifier */
ulong  Capabilities;        /* server capabilities */
ulong  SystemTimeLow;       /* server time - low bytes */
ulong  SystemTimeHigh;      /* server time - high bytes */
short  ServerTimeZone;      /* time zone */
uchar  EncryptionKeyLength; /* set to 0 or 8 */

The 'MaxBufferSize' field is defined in the 'MSDN Open Specifications Developer
Center' as:

"MaxBufferSize (4 bytes): Maximum size, in bytes, of the server buffer for 
sending and receiving SMB messages. This is the size of the largest message 
that the client may send to the server.
This is the size of the buffer used for
the SMB message from the start of the SMB header to the end of the packet."

By sending a crafted response packet containing a small 'MaxBufferSize' value,
it is possible trigger a kernel pool corruption on several Microsoft Windows
operating
systems.

Impact
------

A remote attacker may be able to remotely execute code with kernel privileges
on affected Windows systems. It should be noted that user interaction is not
necessary for exploitation. NetBIOS Name Service (NBNS) packets can easily be
spoofed, or the browser election protocol can be abused to poison the 
neighbourhood cache.

Affected products
-----------------

- Microsoft Windows XP, Server 2003 and earlier versions are affected
- Microsoft Windows Vista and 7 are affected by a variant of this vulnerability.

A race condition in the second negotiation transaction can cause a remote denial
of service. See Microsoft advisory for more details:
- http://go.microsoft.com/fwlink/?LinkId=178850

Technical details
-----------------
The following analysis has been performed on an up-to-date Windows XP SP3 with
version 5.1.2600.5700 of the driver mrxsmb.sys. The underlying issue is similar
on other affected platforms, but the code path leading to the pool corruption 
is different. 

The issue is triggered by sending to the client a 'Negotiate
Protocol' response with a small 'MaxBufferSize' value. In the function 
mrxsmb!SmbCeInitializeExtendedSessionSetupExchange, the SMB client adds 80h to 
the 'MaxBufferSize' value sent by the server and requests a kernel pool chunk 
of the corresponding size:

kd> u mrxsmb!SmbCeInitializeExtendedSessionSetupExchange+0x65
mrxsmb!SmbCeInitializeExtendedSessionSetupExchange+0x65:
f6e30937 51          push ecx     ; PoolTag = 0x734b6d53 ('SmKs')
f6e30938 0580000000  add eax, 80h ; add 80h to 'MaxBufferSize' value
f6e3093d 50          push eax     ; Requested size
f6e3093e 6a01        push 1
f6e30940 e8ce1dfdff  call mrxsmb!_RxAllocatePoolWithTag (f6e02713)

The stack trace when the incorrect call to RxAllocatePoolWithTag is performed 
is shown below :

kd> kc
rdbss!_RxAllocatePoolWithTag
mrxsmb!SmbCeInitializeExtendedSessionSetupExchange+0x73
mrxsmb!SmbCeReferenceSession+0x144
mrxsmb!SmbCeInitiateExchange+0xf5
mrxsmb!SmbCeEstablishConnection+0xaf
mrxsmb!MRxSmbCreateVNetRoot+0x15a
[...]

The SMB client then builds the SESSION_SETUP_ANDX_REQUEST packet that is to be
sent back the server. 
In the function mrxsmb!SmbExtSecuritySessionSetupExchangeStart, the SMB headers
are copied starting at offset 80h from the beginning of the previously 
allocated chunk. The amount of space available is controlled by the 
'MaxBufferSize' value sent, and there is no check that the allocated buffer is
large enough. Any data copied after 'MaxBufferSize' bytes overwrites the 
adjacent pool header and data.

kd> uf mrxsmb!SmbExtSecuritySessionSetupExchangeStart
[...]
f6e30813 8bb730010000 mov esi,dword ptr [edi+130h]  ; esi = offset 80h
                                                    ; in allocated buffer
f6e30819 c706ff534d42 mov dword ptr [esi],424D53FFh ; create SMB headers
f6e3081f c6460918 mov byte ptr [esi+9],18h          ; possible out-of-
f6e30823 66c7460a03c8 mov word ptr [esi+0Ah],0C803h ; bound write
f6e30829 66c7461afffe mov word ptr [esi+1Ah],0FEFFh ;
;(according to 'MaxBufferSize')
[...]

A carefully crafted SMB response with an appropriate 'MaxBufferSize' field may
allow arbitrary code execution.

Solution
-------- 

Apply appropriate security patches published by Microsoft related to this 
issue.Alternatively, block access to network ports 139 and 445 using a 
host based firewall.

Response timeline
-----------------

11/11/2009: Issue discovered.
23/11/2009: Microsoft Security Response Center (MSRC) notified.
23/11/2009: MSRC acknowledges receipt of advisory.
27/11/2009: MSRC confirms the issue on XP and Server 2003.
11/12/2009: MSRC confirms issue across all platforms (2000 SP4 - Windows 7)
11/12/2009: Patch release date agreed as 12/01/2010.
05/01/2010: MSRC delays the patch to 09/02/2010.
30/01/2010: Advisory publication date agreed as 09/02/2010
09/02/2010: Coordinated disclosure.

References
----------

 * Vendor advisory: http://go.microsoft.com/fwlink/?LinkId=178850
 * CVE item: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-0016
 * CVE item: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-0017


===============================================================================

About stratsec
--------------
Stratsec, specialises in providing information security consulting and testing
services for government and commercial clients. Established in 2004, we are
now one of the leading independent information security companies in the
Australasian and SE-Asian region, with offices throughout Australia and in
Singapore and Malaysia. 

For more information, please visit our website at http://www.stratsec.net/ 

===============================================================================
-- 
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.
http://www.mailguard.com.au/mg

Powered by blists - more mailing lists