Archive for the ‘SMB’ Category

EMC Support for the SMB 3.0 Protocol – the Future of Storage Protocols

One of the key issues this blog has covered recently is the transformation of storage.  Microsoft is focused on helping customers control the costs of storage, whether by using industry-standard hardware or simplifying existing hardware infrastructure.  To that end we have made significant investments in the SMB 3.0 protocol for file-based storage.  This helps customers use existing network infrastructure to achieve Fibre Channel-like performance, regardless of the underlying storage subsystem.

EMC has announced support for the Server Message Block 3.0 protocol in their VNX and VNXe product lines and published a brief paper entitled, “EMC VNX and VNXe with Microsoft SMB 3.0 – The best of NAS and SAN without compromise.”  It’s a great read.

In it, they highlight the benefits of SMB 3.0 and how storage that uses it can offer the performance and capabilities comparable to traditional SAN storage.  With solutions based on SMB 3.0 you can avoid the costs of Fibre Channel implementations.

The paper also highlights how SMB 3.0 is the future of storage protocols – providing the performance and availability customers need to move mission-critical workloads to network-attached storage platforms based on SMB 3.0.

EMC and Microsoft are performing regular interoperability tests, so you can confidently deploy EMC VNX and VNXe products in a Windows Server 2012 environment. These EMC products are compatible with the SMB 3.0 functionality provided by Windows Server file servers with transparent failover that we discussed in a previous post.

Microsoft is committed to helping customers reduce the costs of storage while managing data efficiently.  SMB 3.0 is an example of how we’re delivering on the commitment and helping to build an ecosystem of storage solutions.

You can read more technical information about our storage capabilities at Jose Barreto’s storage blog on TechNet.  You can also explore SMB 3.0 and many other storage capabilities hands-on by downloading the Windows Server 2012 R2 Preview here – which will become generally available October 18. 

My Sweet Valentine – the CIFS Browser Protocol Heap Corruption Vulnerability

February 17th, 2011 Comments off

On Valentine’s Day, an anonymous researcher announced a previously undisclosed SMB (Server Message Block) vulnerability affecting the CIFS (Common Internet File System) browser service. Along with the vulnerability, the researcher also posted Proof-of-Concept (PoC) exploit code showing exactly how to exploit the vulnerability, triggering a blue screen in kernel mode.


Considering the issue was disclosed without providing any time for remediation or a patch, we analyzed the vulnerability and immediately released edge-based protection (Vuln:Win/SMB.Browser.DoS!NIS-2011-0003) for our Forefront Threat Management Gateway customers.  Luckily, the PoC was not fully weaponized (that is, it was not designed to achieve remote code execution, just a denial of service) although it has been reported as being a remote code execution vulnerability.  Our colleagues at SRD have analyzed the vulnerability and drawn conclusions as to whether RCE is possible and under what circumstances.  Their blog has the details.


Let’s talk a little bit more about this vulnerability and the consequences of exploiting this issue.  As stated by the researcher who disclosed it, the vulnerability is inside an error-reporting function of the CIFS browser service module. The function gets a variable number of arguments as parameters. Those string arguments are pushed on the stack for processing. In some cases, some of the strings can be controlled by the attacker.


An attacker triggers the vulnerability by causing multiple string arrays to be concatenated. The target buffer to which the concatenated string arrays are pushed has a pre-allocated fixed size.  When the remaining target buffer length becomes 0, the string copy loop should exit, but it does not. The length is decremented by one more before the actual string copy instructions are executed, which is intended to reserve the string’s NULL termination. Suddenly, the length of the string to be copied becomes a huge number due to the integer underflow. The next string copy operation will attempt to copy an extremely large number of bytes from the source address to the target buffer, and then the overflow ensues.


Our conclusion is that the part of the string that the attacker can control will always end up inside the allocated buffer, and the part the attacker can’t control is in the part that overflows the buffer.  Also, it is not possible to control the length of data to overwrite, so that it’s always the same (and predictable) huge integer value.  As a result, we don’t (yet) see how RCE can happen.


In any case, our coverage was released late on Valentine’s Day right around the time most of you were (hopefully) enjoying your Valentine’s Day desserts.


– Matt (Jeong Wook) Oh and the MMPC Vulnerability Response Team