CORE SECURITY TECHNOLOGIES
                              http://www.corest.com

                   Vulnerability report for Windows SMB DoS

Date Published: 2002-08-22

Last Update: 2002-08-22

Advisory ID: CORE-20020618

Bugtraq ID: N/A

CVE: CAN-2002-0724

CERT: VU#311619, VU#342243,VU#250635

Title: Denial of Service Vulnerabilities in Windows SMB implementation

Class: Implementation flaws

Remotely Exploitable: Yes

Locally Exploitable: Yes

Advisory URL: http://www.corest.com/common/showdoc.php?idx=262&idxseccion=10

Vendors contacted:

Microsoft Corporation
.CORE notification: 2002-07-11
.Notification acknowledged by MS: 2002-07-12
.MS initial fix provided: 2002-07-26
.CORE tested fix: 2002-07-29
.MS final testing and statements: 2002-08-22

Release Mode: COORDINATED RELEASE

Vulnerability Description:

SMB stands for "Server Message Block" and is also known as CIFS
(Common Internet File System).
This protocol is intended to provide an open cross-platform
mechanism for client systems to request file services from server
system over a network.
Current CIFS implementation under Windows runs over port tcp/139
and/or port tcp/445 (Direct Host), depending whether NetBIOS over
TCP/IP is enabled or not.

The SMB_COM_TRANSACTION command allows the client and the server
to define functions specific to a particular resource on a
particular server. The functions supported are not defined by the
protocol itself but by client and server implementations.

By sending a specially crafted packet requesting the NetServerEnum2,
NetServerEnum3 or NetShareEnum transaction, an attacker can mount a
denial ofservice attack on the target machine.
It might be possible to abuse this vulnerability to execute arbitrary
code, although the research performed so far can not confirm this
possibility (see 'Technical Description' below for more precise
information).

In order to exploit this vulnerability a user account is needed for
the NetShareEnum transaction and only anonymous access is necessary
for NetServerEnum2 and NetServerEnum3.

Windows operating system ship with anonymous access enabled by default
and are therefore vulnerable to a denial of service attack.

The effect of an attack will trigger a operating system halt (Blue Screen)
as shown below (memory addresses may vary):

*** STOP: 0x0000001E (0xC0000005, 0x804B818B, 0x00000001, 0x00760065)
KMODE_EXCEPTION_NOT_HANDLED
*** Address 804B818B base at 80400000, DateStamp 384d9b17 0 ntoskrnl.exe

The physical memory is dumped and the system restarted (unless configured
otherwise).

Vulnerable Systems:

The problem was identified and tested on:

• Windows NT 4.0 Workstation/Server
• Windows 2000 Professional/Advanced Server
• Windows XP Professional

With all service packs and security hotfixes applied

Solution/Vendor Information/Workaround

Microsoft has released a fix to the problem.
Refer to Microsoft Security Bulletin MS02-045 for patches
and fixes to vulnerable systems.

http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/MS
02-045.asp

Workarounds

• Disable anonymous access (NULL connections)
  This will not prevent legitimate users from abusing the vulnerability.

• Block access to the SMB ports from untrusted networks.
  Blocking access to ports tcp/445 and tcp/139 at the network perimeter
  will prevent attacks from untrusted parties. However, this is not
  a viable solution for environment were file and printing services
  are needed for legitimate users.

• Shutdown the Lanman server (net stop lanmanserver)
  This prevents exploitation from any attacker but removes all file
  and print sharing functionality from the vulnerable server. It might
  not be a viable solution in many environments.

Credits:

These vulnerabilities were discovered and researched by Alberto Solino
and Hernan Ochoa of the Security Consulting Services team at CORE SECURITY
TECHNOLOGIES.

Technical Description - Exploit/Concept Code

The following analysis was performed on a Windows 2000 Advanced Server
(Service Pack 2).

The attack consists of sending (after establishing a SMB session) a
specially
crafted SMB_COM_TRANSACTION packet requesting the NetServerEnum2,
NetServerEnum3
or NetShareEnum functions of the Microsoft Windows Lanman Remote API
Protocol.

The format of this packet consist of a SMB Header plus the Transaction
request.
The transaction request has the following format:

Transaction Request Format

+0 Word Count (BYTE)
+1 Total Parameter Count (WORD)
+3 Total Data Count (WORD)
+5 Max Param Count (WORD)
+7 Max Data Count (WORD)
+9 Max Setup Count (BYTE)
+10 (0Ah) Reserved (BYTE)
+11 (0Bh) Flags (WORD)
+13 (0Dh) Timeout (DWORD)
+17 (11h) Reserved (WORD)
+19 (13h) Parameter Count (WORD)
+21 (15h) Parameter Offset (WORD)
+23 (17h) Data Count (WORD)
+25 (19h) Data Offset (WORD)
+27 (1Bh) Setup Count (BYTE)
+28 (1Ch) Reserved (BYTE)
+29 (1Dh) Byte Count (WORD)
+31 (1Fh) Transaction Name '\PIPE\LANMAN\x00' (13 BYTES)
+44 (2Ch) Parameters

Parameters

+0 Function Code (WORD)
+2 Parameter Descriptor (6 BYTES)
+8 Return Descriptor (7 BYTES)
+15 (0Fh) Detail Level (WORD)
+17 (11h) Receive Buffer Length (WORD)

The 'Function Code' found in 'Parameters' specifies the function requested.
In this case it must be 68h (NetServerEnum2), D7h (NetServerEnum3) or
00h (NetShareEnum).

The problem arises when the fields 'Max Param Count' and/or 'Max Data Count'
are set to zero (0).

Once the request packet is received by the Windows server, it is handled by
the SRV.SYS driver in kernel mode.
At SRV.SYS+08F4h it is determined that the packet is a SMB_COM_TRANSACTION
and a function we arbitrary named 'doSMB_COM_TRANSACTION' (SRV.SYS+D42A) is
called where the Transaction Request portion of the packet is parsed.

Here the 'Max Data Count' and 'Max Param Count' (and all other fields) are
extracted from the packet received, some calculations and sanity checks are
performed to determine the location of the 'Parameters' in the transaction
request packet and the amount of memory needed to store them.
A function is then called at SRV.SYS+DAB0 to allocate a structure in the
heap
(BUFFER1 from now on) that will contain data obtained from the transaction
packet and the 'Parameters':

[…]
0000DADB movzx eax, si
0000DADE mov [ebp+var_4], eax
0000DAE1 add eax, 3
0000DAE4 mov ecx, eax
0000DAE6 mov [ebp+var], eax
0000DAE9 mov eax, [ebp+argC_MaxDataCountAdded]
0000DAEC and ecx, 0FFFFFFFCh ; align
0000DAEF cmp eax, 10400h ; the max of the data with
; everything added is 66560
0000DAF4 lea edi, [ecx+eax+98h] ; Calculate the space
; needed for the
structure
; + the 'Parameters'
0000DAFB mov [ebp+argC_MaxDataCountAdded], edi
0000DAFE ja short loc_1DB22
0000DB00 cmp [ebp+arg_1C], 0
0000DB04 jnz locAllocateHeap
[…]

[…]
0001B806 locAllocateHeap:
0001B806 lea eax, [ebp+1Ch]
0001B809 push eax ; ptr to buffer that will
contain
; error code
0001B80A push edi ; Bytes to allocate
(calculated
; above at SRV.SYS+DAF4)
0001B80B call myAllocateHeap
0001B810 jmp loc_1DB20
[…]

Later in the processing of the request, at SRV.SYS+33209h another buffer
will be
allocated in the heap. This buffer (BUFFER2) will be next to the one
allocated
at SRV.SYS+1B806h (BUFFER1).

The problem is that due to the lack of proper checks and miscalculation,
when the
'Max Data Count' and/or 'Max Param Count' are zero, the length of the first
buffer
allocated on the heap (BUFFER1) will be insufficient and the first 8 bytes
of the
next chunk on the heap (used by the ntoskrnl!RtlFreeHeap() algorithm) will
be
overwritten.

When the first buffer allocated is freed by calling ntoskrnl!RtlFreeHeap()
the heap
will be in an inconsistent state (due to the corruption of the chunk's
'control'
data, used by the ntoskrnl!RtlFreeHeap() algorithm) and RtlFreeHeap() will
try to
access an invalid memory address resulting in the system crash (Blue
Screen).

The actual corruption of the heap occurs as result of a LPC message sent by
SRV.SYS
to the Lanman Server Service (implemented in srvsvc.dll, running in user
mode).

At SRV.SYS+33358, an LPC message to the Port '\\XactSrvLpcPort' is sent
(This port is created by srvsvc.dll):

[…]
00033336 push [ebp+arg_0]
00033339 call myImpersonateSecurityContext
0003333E xor esi, esi
00033340 mov [ebp+errorCode], eax
00033343 cmp eax, esi
00033345 jl short loc_43366
00033347 lea eax, [ebp+varReplyMessage]
0003334D push eax ; OUT PPORT_MESSAGE
ReplyMessage
0003334E lea eax, [ebp+varRequestMessage]
00033351 push eax ; IN PPORT_MESSAGE
RequestMessage
00033352 push myPortHandle ; IN HANDLE PortHandle
00033358 call ds:NtRequestWaitReplyPort
0003335E mov [ebp+errorCode], eax
[…]

This message is handled by srvsvc.dll where function to be called is
obtained
from a message table, described below as 'PortFuncMsgTable':

[…]
767E88A3
767E88A3 mov [ebp+var_CC], 10h
767E88AC mov [ebp+var_CA], 28h
767E88B5 mov [ebp+var_C8], esi
767E88BB mov eax, [ebp+var_88]
767E88C1 mov [ebp+var_C4], eax
767E88C7 mov eax, [ebp+var_84]
767E88CD mov [ebp+var_C0], eax
767E88D3 mov eax, [ebp+var_80]
767E88D6 mov [ebp+var_BC], eax
767E88DC mov eax, [ebp+var_78]
767E88DF cmp eax, 0Ah
767E88E2 ja Func3
767E88E8 jmp ds:PortFuncMsgTable[eax*4]
[…]

This ends up calling the function at SRVSVC.DLL:767EE136, that receives the
buffer
allocated (BUFFER1) in kernel mode by the SRV.SYS driver.

The function then checks again the Parameters of the transaction request, by
calling different functions in xactsrv.dll:

[…]
767EE1B1 push eax
767EE1B2 push ebx
767EE1B3 call pfXsCheckSmbDescriptor ;
XsCheckSMBDescriptor is located in
; xactsrv.dll (7568d46f)
767EE1B9 test eax, eax
767EE1BB jnz loc_767EE2A1
[…]

XsCheckSMBDescriptor performs some checks and processing of the Parameters
and
Return Descriptor of the SMB Transaction request. Then the function
'XsCaptureParemters' is called to perform further processing:

[…]
767EE2A1 lea eax, [ebp-0D0h]
767EE2A7 push eax
767EE2A8 push dword ptr [ebp-20h] ; ptr to 'BUFFER1'
structure
767EE2AB call pfXsCaptureParameters
767EE2B1 mov [ebp-1Ch], eax
[…]

At xactsrv!7568D2D5 the 5th byte after the end of BUFFER1 is overwritten
with a 0:

[…]
7568D2D5 movzx ecx, ax
7568D2D8 mov [esi], ax
7568D2DB mov edi, [edx+48h]
7568D2DE mov edx, ecx
7568D2E0 xor eax, eax
7568D2E2 shr ecx, 2
7568D2E5 repe stosd
7568D2E7 mov ecx, edx
7568D2E9 and ecx, 3
7568D2EC repe stosb ; here the 5th byte is overwritten
7568D2EE jmp short loc_7568D33D
[…]

After returning from this call, based on the Function Code of the
transaction,
the requested function is called in xactsrv.dll (XsNetServerEnum2,
XsNetServerEnum3,
or XsNetShareEnum in this case)

[…]
767EE22F mov dword ptr [ebp-4], 2
767EE236 push dword ptr [ebp-0D0h]
767EE23C push dword ptr [ebp-0DCh]
767EE242 push ebx
767EE243 push dword ptr [ebp-1Ch]
767EE246 call dword ptr table_767F2E38[edi] ; 'function'
table
[…]

Inside the called function (XsNetServerEnum2 or XsNetServerEnum3) another
function,
browser.dll!I_BrowserServerEnumForXactSrv, will be called. The value
returned
from this function will later be used to overwrite the heap.
The observed return values that are used to overwrite the heap were 17E6h
and 7Ch.
It is not evident that this values can be controlled by the attacker in a
reliable
way.

[…]
75688823 add eax, 64h
75688826 push eax
75688827 push [ebp+var_38]
7568882A push ebx
7568882B call I_BrowserServerEnumForXactsrv
75688830 mov [edi], ax ; ax contains returned value
; this value will be the one
; used to overwrite the heap
75688833 test ax, ax
75688836 jz short loc_75688844
[…]

Finally after some more processing the function will return to
srvsvc.dll!767ee24c after
executing the function requested (XsNetServerEnum2, XsNetServerEnum3 or
XsNetShareEnum)

Some other processing with the returned number will be done and the
XsSetParameter
function will be called. This call will effectively overwrite the first two
bytes after
the BUFFER1 structure with the value returned from the call to
browser.dll!I_BrowserServerEnumForXactSrv, and then the 3rd and 4th byte
will be
overwritten with 0.

[…]
767EE28C push dword ptr [ebp-0A0h]
767EE292 push edi
767EE293 push dword ptr [ebp-20h]
767EE296 call pfXsSetParameters ; Call to
XsSetParameters
[…]

[…]
XsSetParameters:
7568DB0D
7568DB0D push ebp
7568DB0E mov ebp, esp
7568DB10 push ecx
7568DB11 mov ecx, [ebp+0Ch]
7568DB14 mov eax, [ebp+10h]
7568DB17 push ebx
7568DB18 push esi
7568DB19 mov esi, [ebp+08h]
7568DB1C mov dx, [ecx]
7568DB1F push edi
7568DB20 push 2
7568DB22 mov ebx, [esi+40h] ; ptr to past the end of
BUFFER1
7568DB25 mov [ebp+10h], eax
7568DB28 mov eax, [esi+3Ch]
7568DB2B pop edi
7568DB2C mov [ebx], dx ; overwrite the first two bytes
7568DB2F mov dx, [ecx+2]
7568DB33 add ebx, edi
7568DB35 add eax, edi
7568DB37 mov [ebx], dx ; overwrite the 3th and 4th byte
[…]

Exploitation of this vulnerability in order to run arbitrary code on the
vulnerable
system is not straight forward and our research so far could not identify a
reliable attack scenario other than to perform a denial of service.

The complexity of exploiting this vulnerability to gain unauthorized access
to
a system or plainly run arbitrary code on it resides on the fact that the
attacker can not completly control the bytes used to overwrite the chunk's
'control'
data nor the bytes contained in BUFFER2 (of which the 'control' data is
overwritten).

We do not discard that further research will demonstrate that arbitrary code
execution is possible.

When the attack is performed using the NetShareEnum function, the corruption
of the
heap also occurs in the call to XsSetParameters, but
I_I_BrowserServerEnumForXactsrv
is not called, and possible values to overwrite the chunk 'control' data are
more
promising in terms of exploiting the problem, but the lack of complete
control of
the data of BUFFER2 again makes it difficult.

Conclusion

The vulnerabilities described in this advisory can be
abused by an attacker in order to conduct a denial of service attack
against the vulnerable system both remotelly and locally using
either an active user's account or logging in using a NULL connection.

Arbitrary execution of code has not been proved but is not discarded
as a possibility.

DISCLAIMER:

The contents of this advisory are copyright (c) 2002 CORE Security
Technologies and may be distributed freely provided that no fee is charged
for this distribution and proper credit is given.

$Id: smbdos.txt,v 1.12 2002/08/22 23:31:32 iarce Exp $

---

Perscriptio in manibus tabellariorum est
Noli me vocare, ego te vocabo

Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES

44 Wall Street - New York, NY 10005
Ph: (212) 461-2345
Fax: (212) 461-2346
http://www.corest.com

PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A

— for a personal reply use: =?iso-8859-1?Q?Iv=E1n_Arce?= <[email protected]>