From core.lists.bugtraq@core-sdi.com Fri Aug 23 14:35:36 2002 From: "[iso-8859-1] Iván Arce" To: BUGTRAQ@securityfocus.com Date: Thu, 22 Aug 2002 20:41:39 -0300 Subject: CORE-20020618: Vulnerabilities in Windows SMB (DoS) [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] 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?=