With the release of Windows 8 scheduled for October 26, Windows security is on our mind. Windows is one of the most widely used operating systems in the world, making it a lucrative target for exploit developers and malware authors. In previous versions of Windows, many security features were introduced, including ASLR, DEP, and pointer encodings. Microsoft utilized software development lifecycle and threat modeling to ensure it was delivering a secure operating system to its users; however, many of previous Windows security exploits were the result of developers overlooking the proper implementation of protocol standards. Supplementing the detailed analysis made available by Microsoft, in this blog post, we share additional analysis of one of these exploits and highlight a short list of additional exploits that were the result of poor security validation.
Microsoft implemented many initiatives focused on developing code that was secure from exploitation of vulnerabilities, but unfortunately, many zero-day vulnerabilities were reported in Windows 2008 and Windows 7.
Let's dive into the analysis of one zero-day CVE-2011-0654 which was reported on February 14, 2011, for Windows 7 and 2008 servers to understand the factor that seems to have been missed to ensure the safety of Windows.
When the publicly available malicious exploit code is executed, the capture is as shown in Figure 1.
It is quite obvious from the capture that the overly long server name ignites the integer overflow vulnerability. Technical analysis of the integer overflow is available on the MSRC’s webpage and hence will not be repeated here. However, we will note that if we refer to the proprietary protocol specification by Microsoft's [MS-BRWS]: Common Internet File System (CIFS) Browser Protocol Specification Section 2.2.3 Request Election Browser Frame on page 22, it can be seen that the server name as specified by specification has to be less than 16 bytes including the null terminator.
So if the value specified by the protocol specification document would have been strictly enforced in the code and validated by the security team, this zero-day would never have happened.
Table 1 lists many more vulnerabilities which again could have been avoided if the values defined by the protocol standards would have been strictly enforced by the developers and further validated by the security team.
|CVE-ID||Trigger Condition for the Vulnerability|
|CVE-2011-0654 CVE-2011-0654||Vulnerable condition gets triggered due to improper implementation of server name in Microsoft Windows Browser Protocol. Vulnerable condition gets triggered due to improper implementation of server name in Microsoft Windows Browser Protocol.|
|CVE-2011-0660 CVE-2011-0660||Vulnerable condition gets ignited due to the improper implementation of the SMB response type with Command Type = 0×25. Vulnerable condition gets ignited due to the improper implementation of the SMB response type with Command Type = 0×25.|
|CVE-2010-0477 CVE-2010-0477||Vulnerability gets ignited when message size is greater than the amount of data. Vulnerability gets ignited when message size is greater than the amount of data|
|CVE-2010-0270 CVE-2010-0270||Vulnerability is due to improper implementation of the SMB Trans2 response for the command type 0×32. Vulnerability is due to improper implementation of the SMB Trans2 response for the command type 0×32.|
|CVE-2009-3676 CVE-2009-3676||Denial of Service condition due to the improper parsing of the NetBIOS length. Denial of Service condition due to the improper parsing of the NetBIOS length.|
|CVE-2009-3103 CVE-2009-3103||Vulnerable condition gets ignited due to the improper implementation of the Server Message Block command negotiate protocol. Vulnerable condition gets ignited due to the improper implementation of the Server Message Block command negotiate protocol.|
From the reported vulnerabilities in Table 1, it seems obvious that the enforcement of conditions specified in the protocol specification has been missed by the security team. As such, identifying the exploitations that arise due to improper implementation of protocol specifications and developing a mitigating solution for such exploitation are not very challenging tasks for a security team. Some of the solutions to identify and mitigate this kind of exploitation had been published in the August 2011 issue of Virus Bulletin.
Hopefully in Windows 8, unlike previous versions of Windows, the security team has properly enforced the conditions described by the protocol specifications to make Windows 8 immune to such exploitation.