Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Today we released MS12-001, which addresses an issue that can enable an attacker to bypass a defense in depth feature known as SafeSEH. This bypass is limited in scope to applications that make use of binaries that were built with Microsoft Visual C++ .NET 2003 RTM. Binaries that have been built with Microsoft Visual C++ .NET 2003 Service Pack 1 and beyond are not affected. In this blog post we wanted to provide more details on the issue that has been addressed and what impact it has. In addition, we’ll clarify the parameters of the “Security Feature Bypass” vulnerability category assigned to this bulletin.
What is SafeSEH?
SafeSEH is a defense–in-depth security feature that is designed to make it more difficult for attackers to exploit certain types of vulnerabilities. In particular, SafeSEH is designed to prevent attackers from using an attack technique known as an “SEH overwrite”. More details on how this is accomplished can be found in a report we released in July of last year: http://go.microsoft.com/?linkid=9776900.
Microsoft released support for SafeSEH in Visual Studio 2003 RTM. Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 were the first versions of Windows to be built with SafeSEH enabled.
What issue is being addressed?
This issue can result in SafeSEH not being enforced for a binary that has been built with support for SafeSEH. This occurs when a binary that was built with Microsoft Visual C++ .NET 2003 RTM is loaded by an application running on a version of Windows that is affected by MS12-001.
The reason that SafeSEH is not enforced in this scenario is because Microsoft Visual C++ .NET 2003 RTM produces binaries with metadata that is a different size than what the Windows loader expects. As a result, the loader conservatively falls back to assuming that the binary does not support SafeSEH. MS12-001 addresses this issue by allowing binaries to have metadata of the size that is produced by Microsoft Visual C++ .NET 2003 RTM.
What impact does this issue have?
Failing to enforce SafeSEH for a binary can enable an attacker to more easily develop an exploit for a vulnerability. The attacker must have found a vulnerability that can enable code execution for this to be possible; the issue addressed by MS12-001 does not enable code execution in and of itself. Furthermore, it does not enable elevation of privilege, information disclosure, or the like. For this reason, we’ve assigned MS12-001 to the very small category of “Security Feature Bypass” vulnerabilities. Though failure to enforce SafeSEH is by no means desirable, the issue in itself does not constitute an exploit vector.
Although the set of binaries affected by this issue is limited, some of the affected binaries are extensively used by applications. For example, the redistributable C runtime DLLs (such as msvcrt.dll) from Visual Studio 2003 are affected by this issue. These DLLs also do not enable support for ASLR and are therefore an attractive target for use in developing an exploit. EMET can be used to better mitigate these concerns by enabling mandatory ASLR and SEHOP for applications that make use of such DLLs.
Do I need to rebuild my binaries if they were built with Visual C++ 2003?
Installing the update for MS12-001 will fully address this issue without requiring any binaries to be rebuilt. Alternatively, this issue can also be resolved by rebuilding affected binaries with Microsoft Visual C++ .NET 2003 Service Pack 1 or later. You can determine if your binary is affected by this issue by using the Microsoft Visual C++ linker command “link.exe /dump /headers binary.dll”. Binaries with a Load Config Directory size of 0x48 are affected as shown below.
File Type: DLL
7.10 linker version
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
3AC74 [ 43E0] RVA [size] of Export Directory
49298 [ 28] RVA [size] of Import Directory
52000 [ 3B8] RVA [size] of Resource Directory
0 [ 0] RVA [size] of Exception Directory
0 [ 0] RVA [size] of Certificates Directory
53000 [ 2B64] RVA [size] of Base Relocation Directory
39B48 [ 38] RVA [size] of Debug Directory
0 [ 0] RVA [size] of Architecture Directory
0 [ 0] RVA [size] of Global Pointer Directory
0 [ 0] RVA [size] of Thread Storage Directory
49078 [ 48] RVA [size] of Load Configuration Directory
Thanks to Gerardo Di Giacomo and our colleagues in Windows Sustained Engineering for their work on addressing this issue.
Matt Miller, MSEC Security Science
Today we released seven security bulletins. One has a maximum severity rating of Critical with the other six having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
Windows 7 not affected by default by either of the two vulnerabilities.
See this SRD blog post for more information.
(SSL / TLS)
- Jonathan Ness, MSRC Engineering
This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.
The most severe of these vulnerabilities is CVE-2012-0003 which is a Critical, Remote Code Execution vulnerability. This CVE affects all editions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Windows 7 is not affected by this vulnerability.
An effective workaround for CVE-2012-0003 is to disable Directshow’s MIDI parsing. Apply the following registry file would unregister the MIDI parser in Directshow.
Windows Registry Editor Version 5.00
CVE-2012-0004 is an Important-class vulnerability also involving Windows Media Player. The vulnerability in the closed caption decoding component (L21 decoder) is contained within DirectShow. Therefore, the multimedia applications that leverage DirectShow to decode closed caption streams might be affected.
As a mitigation, the latest WMP player, WMP12, has closed caption turned off by default. As shown in the below picture, the setting to display close caption content is disabled. Therefore, WMP12 users are not affected by this vulnerability by default.
MS12-004 is our top-priority bulletin for January 2012; though the mitigation described above is effective and we have seen no exploitation attempts against either of the CVEs covered, we recommend that customers apply the bulletin as soon as possible.
Special thanks to Jeremy Tinder in MSRC and Ali Rahbar in MSRC Engineering.
- Chengyun Chu, MSRC Engineering