Earlier this week a PoC exploit for a vulnerability in the BROWSER protocol was released on Full Disclosure. There has been some discussion regarding whether this issue can result in Remote Code Execution (RCE) or is only a Denial of Service (DoS). This blog post provides details on the exploitability based on our internal analysis.
Which systems are vulnerable
All versions of Windows are vulnerable, although the issue is more likely to affect server systems running as the Primary Domain Controller (PDC). In environments following best practices, the BROWSER protocol should be blocked at the edge firewalls thus limiting attacks to the local network.
The BROWSER protocol operates on top of SMB and is used to discover machines and resources on the network. It is implemented as a kernel driver (mrxsmb.sys or bowser.sys, depending on the version of Windows). This vulnerability affects Windows machines that have been configured to (A) use the BROWSER network protocol and (B) that then become Master Browser on the local network. The BROWSER protocol uses an election process to determine which system will act as the “master” in terms of data collection and response handling.
In normal enterprise networks the Primary Domain Controller (PDC) will become Master Browser, but depending on the network configuration, other computers on the network can become Master Browser, and therefore be vulnerable. A single system will be Master Browser at any point in time. (See the [MS-BRWS] protocol specification for more details).
Root cause of the vulnerability
A malformed BROWSER message would cause the Master Browser to hit the vulnerable code below and trigger the vulnerability.
The vulnerability is due to an integer underflow where a 32-bit length value becomes -1. This is then used in a memcpy call as follows:
if ( Length > 0 ) {
RtlCopyMemory(StringOffset, InsertionString, <span style="background-color: #ffff00;">Length*sizeof(WCHAR)</span>);
The copy length will therefore be -2 (0xFFFFFFFE) on 32-bit systems, and 0x1FFFFFFFE on 64-bit systems. This leads to a kernel pool buffer overrun in the context of a thread running at the PASSIVE IRQ level on Windows XP and Windows Server 2003. On Vista and later platforms, the thread will be running at the DISPATCH IRQ level. Threads running at PASSIVE IRQ level can be pre-empted by the operating system, making exploitation slightly more likely.
Effects of the buffer overrun
The copy operation will cause a bugcheck when invalid memory is referenced either from the source or destination address. This bugcheck is almost guaranteed to happen, since roughly 4GB of contiguous memory will be referenced during the copy on 32-bit systems. (On 64-bit systems, roughly 8GB of contiguous memory will be referenced)
It is impossible to have 4GB of contiguous virtual address space mapped at both the source and destination on 32-bit systems. Having 8GB of contiguous virtual address space mapped may be possible on 64-bit systems with sufficient physical memory.
RCE may also be possible if the corrupted memory is used before the RtlCopyMemory triggers a bugcheck, and in a way that can be used to change code execution. For instance, a thread running in another processor may reference the corrupted memory in parallel (while the RtlCopyMemory operation is in progress). On platforms where the copy operation is done at the PASSIVE IRQ level, the thread could be pre-empted by a higher-priority thread or hardware interrupt. Should this happen, the higer-priority thread may reference corrupted memory in a way that can lead to RCE.
We feel that triggering these timing conditions reliably will be very difficult.
Exploitability for RCE
Based on the conditions outlined above, while RCE is theoretically possible, we feel it is not likely in practice. DoS is much more likely.
Looking at the Exploitability Index (XI) rating scale, we would assign this an XI rating of ‘3’ – Functioning exploit code unlikely on Windows Vista and higher. On Windows XP and Wndows Server 2003, the XI rating would be ‘2’ – Inconsistent exploit code likely.
Thanks to Brian Cavenah and Matt Miller for their input. The Microsoft Malware Protection Center (MMPC) blog also has some notes on this issue that you can find here: http://blogs.technet.com/b/mmpc/archive/2011/02/16/my-sweet-valentine-the-cifs-browser-protocol-heap-corruption-vulnerability.aspx
- Mark Wodrich, MSRC Engineering
Updated 2/18/11: Updated the IRQ level information and XI rating based on additional internal research.