Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
*** UPDATE: Version 2.0 of EMET is now available. Click here to read more about it. ***
Even as you read this, people around the world are hunting for vulnerabilities in software applications. Odds are some of them will be successful. Depending on their motives and what they find, your software and systems may be put at risk. So how do you protect your software from unknown vulnerabilities that may or may not exist? One option is to use security mitigations.
Microsoft offers a number of different mitigation technologies that are designed to make it more difficult for an attacker to exploit vulnerabilities in a given piece of software. Take a look at Michael Howard’s article “Protecting Your Code with Visual C++ Defenses” (http://msdn.microsoft.com/en-us/magazine/cc337897.aspx) for a brief overview of some of these technologies.
To help on this front, we are announcing the initial release of a new utility called the Enhanced Mitigation Evaluation Toolkit (EMET). Version 1.0.2 is now available, free of charge at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=162309). This utility builds on our current offerings in several key ways:
1. Until now, many of the available mitigations have required for an application to be manually opted in and recompiled. EMET changes this by allowing a user to opt in applications via a simple command-line utility without recompilation. This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available.
2. EMET provides a higher degree of granularity by allowing mitigations to be applied on a per process basis. There is no need to enable an entire product or suite of applications. This is helpful in situations where a process is not compatible with a particular mitigation technology. When that happens, a user can simply turn EMET off for that process.
3. Mitigations that have previously been limited to up-level versions of Microsoft Windows now ship with EMET and are available down-level. Users can benefit from these mitigations without the need to upgrade their systems.
4. EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from mitigations before they are included in the next versions of our products. It also gives users the opportunity to provide feedback and help guide the future of mitigation technologies in Microsoft products.
This initial release of EMET is primarily focused on providing an extensible framework that will have future mitigations added to it. A total of four mitigations are also being included with this release and are listed below. We will provide announcements as future mitigations are added. If you have ideas about mitigations you’d like to see (whether they already exist or not) feel free to contact us.
This mitigation performs Structured Exception Handling (SEH) chain validation and breaks SEH overwrite exploitation techniques. Take a look at the following SRD blog post for more information: http://blogs.technet.com/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx. With this protection in place, the msvidctl exploit we already blogged about (http://blogs.technet.com/srd/archive/2009/07/28/msvidctl-ms09-032-and-the-atl-vulnerability.aspx) would have failed.
Data Execution Prevention (DEP) is a memory protection mitigation that marks portions of a process’ memory non-executable. This makes it more difficult to an attacker to exploit memory corruption vulnerabilities. For more information on what DEP is and how it works, take a look at the two part SRD blog available at http://blogs.technet.com/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx and http://blogs.technet.com/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-2.aspx.
This blocks attackers from being able to take advantage of NULL dereferences in user mode. It functions by allocating the first page of memory before the program starts. Right now the exploitation techniques for these types of vulnerabilities are only theoretical. However, this mitigation will protect you even if that changes. Please note this protection does not impact kernel mode NULL dereferences as the current version of EMET only supports user mode mitigations.
Heap spraying is an attack technique that involves filling a process’ heap with specially crafted content (typically including shellcode) to aid in exploitation. Right now, many attackers rely on their content being placed at a common set of memory addresses.
This mitigation is designed to pre-allocate those memory addresses and thus block these common attacks. Please note that it only aims to break current exploit that take advantage of these common addresses. It is not a general mitigation for the larger heap spraying attack. That said, if attackers do change the addresses they use, EMET users can change the addresses
Security mitigations carry an application compatibility risk with them. Some applications rely on precisely the behavior that the mitigations block. For this reason mitigations are typically turned off by default and require opt-in from a developer before they are enabled. While EMET allows users to override this, it is important to be aware of the risk. EMET is intended for tech savvy users such as IT professionals and security researchers who can troubleshoot issues that these mitigations may introduce. We also recommend testing your applications and use scenarios with these mitigations prior to deploying them on any production systems.
We encourage you to download and try out the tool. If you have any feedback on your experiences with the tool, you can reach us at email@example.com.
Special thanks to Matt Miller for his assistance with EMET.
- Fermin J. Serna and Andrew Roths, MSRC Engineering
MS09-054 addresses an IE vulnerability (CVE-2009-2529), which was discovered and presented by Mark Dowd, Ryan Smith, and David Dewey at the BlackHat conference in July.
First we’d like to make it clear that any customers that have applied the update associated with MS09-054 are protected, regardless of the attack vector. And most customers need not take any action as they’ll receive this update automatically through Automatic Updates.
For those customers that are evaluating whether or not to deploy this update, and want more information on how to protect themselves until they do, we’ve provided more details in this blog post to help understand this vulnerability.
What’s the attack vector?
A browse-and-get-owned attack vector exists. All that is needed is for a user to be lured to a malicious website. Triggering this vulnerability involves the use of a malicious XBAP (XAML Browser Application). Please not that while this attack vector matches one of the attack vectors for MS09-061, the underlying vulnerability is different. Here, the affected process is the Windows Presentation Foundation (WPF) hosting process, PresentationHost.exe.
While the vulnerability is in an IE component, there is an attack vector for Firefox users as well. The reason is that .NET Framework 3.5 SP1 installs a “Windows Presentation Foundation” plug-in in Firefox, as shown below.
Via this plug-in it is possible to launch XBAP, and reach this vulnerability, from within Firefox.
How can I protect myself?
Customers should apply MS09-054 as this addresses the underlying vulnerability for all users, both IE and Firefox. While you’re evaluating and testing your deployment of MS09-054, you may want to consider the following workarounds.
For IE users, our recommended workaround is to disable XBAP in the Internet zone. By default, IE8 on Win2k8 and Win2k3 already has XBAP disabled in the internet zone. For others, you can disable XBAP via the following security setting in IE.
For Firefox users with .NET Framework 3.5 installed, you may use “Tools”-> “Add-ons” -> “Plugins”, select “Windows Presentation Foundation”, and click “Disable”.
Big thanks to David Ross, Fermin J. Serna, and Andrew Roths from the MSRC Engineering Team, Eric Lawrence and Jeremy Reed from IE team, and Jennifer Lee from WPF team.
Updated October 16, 2009 - updated blog post to clarify that Firefox users are protected from CVE-2009-2529 if they install the MS09-054 update.
This month we are releasing update MS09-050 to address the SMBv2 RCE vulnerability (CVE-2009-3103). Due to the fact that public exploit code exists for this vulnerability, we felt it would be good to summarize the exploit landscape at the time of release, so customers can use this information to prioritize the deployment of the update.
The initial public disclosure of this vulnerability on Sept. 7, 2009 included proof-of-concept code which would lead to a denial of service (DoS) due to the targeted system rebooting. Microsoft immediately began working to understand the vulnerability and produce a high-quality update. From an early stage we realized this vulnerability posed a Remote Code Execution (RCE) threat, and we released a security advisory to notify customers of the risk and suggested a work-around (disabling SMB2) which would protect systems from attack until the official update was ready.
One week later on Sept. 14, a security company released proof-of-concept code for a local exploit. On Sept. 17, the same company released proof-of-concept code for a remote exploit. The security company provided the local and remote exploit only to a subset of their customers who subscribe to an “early update” package. I will refer to this exploit as the “commercial exploit”.
Microsoft analyzed the commercial exploit code to determine the risk to customers and gauge how likely it would be for other security researchers to achieve a working exploit. Based on this analysis, we determined that the exploit provided was reliable, and that there was low risk of active exploitation (due to the limited release of the exploit). We continued to test the update and work towards releasing it as soon as it reached an acceptable quality level, barring changes in the exploit landscape.
At this time we were also aware that other researchers in the security community were working towards a remote exploit, and that they were planning to include it in freely-available tools. On Sept. 28, the first public exploit code was released. Again, we analyzed the exploit to determine the risk to our customers. We determined that the exploit was not reliable on all systems and would only work on a limited number of configurations reliably.
On Oct. 4, a blog post outlined changes to the public exploit code that would improve its reliability, but did not detail the exact code changes required. The post provided enough technical detail that we knew it would not take long for the public exploit to be updated, and a few days later we saw updated public exploit code posted online. At about the same time, the commercial exploit was also released to the security company’s wider set of customers.
Microsoft analyzed the newest public exploit code and determined that it was not yet reliable. (In fact it seemed to be totally unreliable in our testing.) We expected the gap between the commercial exploit and the public exploit to quickly close as more people gained access to the commercial exploit, and more people worked with the public exploit.
There is currently no functioning RCE exploit for 64-bit systems running 64-bit Windows. The current commercial and public exploit tools only work against 32-bit Windows systems, and developing a reliable exploit for 64-bit Windows should be very difficult. However, 64-bit SMB servers are still at risk of DoS attacks using this vulnerability.
A reliable remote exploit is not widely available for 32-bit systems, and the risk of widespread attacks against systems is currently low. However, that could change at any moment.
I would like to thank the Windows SMB and Windows Serviceability teams for their hard work on this update, Jonathan Ness and Bruce Dang for the SMBv2 workaround and "Fix-It" automation, and Brian Cavenah and Ken Johnson for technical advice and help analyzing the exploits.
- Mark Wodrich
MS09-056 addresses two vulnerabilities that affect how the Windows CryptoAPI parses X.509 digital certificates. Applications on the Windows platform as well as Windows components such as the WinHTTP API can call into the CryptoAPI which provides cryptographic services to validate digital certificates. Internet Explorer, for instance, uses the CryptoAPI to parse and validate the certificate of remote web servers while browsing.
Digital certificates can prove that one peer in an SSL connection is who he claims to be. They are signed by a trusted, independent third party known as a Certificate Authority. Most often used to protect communications to web sites, they are also in common use to protect e-mail communications or B2B connections. The X.509 standard describes what information can go into a certificate and uses ASN.1 (Abstract Syntax Notation 1) to describe the format of the data. Object Identifier or OID is the ASN.1 type used to identify specific elements of the certificate such as an algorithm or attribute type. For example “126.96.36.199” is the OID that identifies the “Common Name” or “CN” string field in a certificate.
Addressed in this security update are a null truncation vulnerability and an integer overflow condition in ASN.1 parsing. Both of these vulnerabilities were discovered and presented by Dan Kaminsky at the BlackHat security conference in Vegas at the end of July of this year.
· CVE-2009-2510: Fields in the certificate’s subject name (such as the ‘Common Name’ or ‘CN’ field) which contains a NULL character in the string will cause the CryptoAPI to parse only the portion of the string prior to the NULL character. However, the certificate may have been issued to the organization / domain that comes after NULL character in the string.
· CVE-2009-2511: In a certificate, each Object Identifier (OID) is stored as a sequence of integers but is converted to a string by CryptoAPI when parsing a certificate. . The ASN.1 standard does not specify a maximum value for integers, but CryptoAPI assumes integer components of an OID can be safely parsed into a 32 bit integer in memory. A specially crafted OID number may result in an integer overflow condition that could cause it to be parsed in a way that allows the OID number’s data to replace the data for the previously encountered OID. This can cause the Certificate Authority and Windows to parse the certificate differently. This vulnerability can be exploited in those cases where the Certificate Authority ignores the specially crafted OID and agrees to sign the certificate, whereas the Windows CryptoAPI does parse the crafted OID.
Both of these vulnerabilities have an impact of spoofing, which means that an attacker could use them to fraudulently spoof the identity of another legitimate server on the internet.
This sounds quite serious and it is. However, it is important to take into account that the effort required in setting up such an attack is extensive. In order to exploit this issue in a web browsing scenario an attacker must successfully complete the following steps:
1. Convince a certificate authority to sign a rogue certificate. This would need to be a Certificate Authority that is present in the Root Certificate store of the Windows machine;
2. Execute a successful man-in-the-middle attack that hijacks the connection from a vulnerable client to a server and present the certificate to the client, e.g. via a DNS spoofing attack or via ARP cache poisoning on a local subnet.
Leveraging an attack which abuses these flaws is not trivial but cannot be excluded. We do believe that the threat of these attacks is significantly mitigated by these requirements posed on the attacker. However, the TLS Handshake Protocol (RFC 2246) makes two security promises that are violated by these vulnerabilities:
· The peer's identity can be authenticated;
· That no attacker can modify the communication without being detected by the parties to the communication.
As this vulnerability shows the potential of breaking this security promise, we consider it important to address these issues and are releasing this security update. We recommend that customers install them at their earliest convenience.
Updates to the CryptoAPI affect a vast number of applications that run on the Windows platform and these require very thorough and stringent testing prior to release. For this specific update our engineers looked specifically for applications that may have been affected by the unique changes made to this API and performed very detailed and specific interoperability testing. Quality of security updates is paramount to Microsoft which for the CryptoAPI often results in a fairly long test cycle.
During the development of these security updates Microsoft has continued to evaluate the threat environment to assess the risk these vulnerabilities posed to our customers. Certificate authorities that are included in the Root Certificate store on Windows are all required to meet the requirements of the Microsoft Root Certificate Program. A list of the third-party certification authorities (CAs) that are trusted by Microsoft and whose root certificates are distributed via the Root Certificate Program can be found in KB article 931125. During the development of these updates the MSRC has worked with certificate authorities to ensure that their systems were also hardened to help prevent signing certificates that may have attempted to exploit these vulnerabilities.
Thanks to Gavin Thomas and Robert Hensing from the MSRC Engineering team and Kelvin Yiu from Windows Crypto for their technical investigation into these two issues.
-Maarten Van Horenbeeck, MSRC Program Manager
This morning we released 13 security bulletins, our largest release of 2009. Altogether, these bulletins address 34 separate CVEs. We’d like to use this blog post to help you prioritize your deployment of the updates.
We’ve provided a prioritized list of bulletins in the table below. The prioritization is based on the following criteria:
1. The bulletins are grouped and sorted according to severity and the exploitability.
2. Within each group we prioritize the bulletins with publicly available exploit code ahead of the others.
3. After that we list bulletins where technical details of the vulnerability have been widely discussed, even if no exploit is publicly available.
4. Finally, we take into account platform mitigations that impact the reliability of exploits.
Most Likely Attack Vector
Max Exploit-ability Index
Likely first 30 days Impact
Browsing to a malicious website or ASF (WMA, WMV) attached to email.
We have reports from partners of limited attacks in-the-wild.
Attacker initiates a network connection to a vulnerable workstation or server. This would most likely be an attacker on the local subnet as SMB is typically blocked by edge firewalls.
We are aware of reliable working exploit code distributed to limited number of customers. We are also aware of unreliable exploit code available publicly. We have not, however, heard of customers being exploited by this vulnerability. We expect working reliable exploit code to be made public within the next 30 days.
Windows Vista not affected in ‘Public’ network profile
Browse to a malicious website.
One of the vulnerabilities addressed was presented publicly at BlackHat. We are not aware of any active exploits for these issues at time of release; however, we expect reliable exploit code to be made public within the next 30 days.
Windows Server 2003, 2008 and 2008 R2 at reduced risk due to Enhanced Security Configuration.
Browse to a website hosting a malicious .NET application that runs in the browser.
One of the vulnerabilities was posted on a public forum. However, we are not aware of any working exploits for the issue or customers who have been impacted. We expect reliable exploit code to be made public within the next 30 days.
Browse to a malicious website or click on an image attached to an email
All vulnerabilities addressed have been responsibly disclosed. We expect reliable exploit code to be made public within the next 30 days.
Windows Server 2003 and 2008 at reduced risk due to Enhanced Security Configuration.
This vulnerability was responsibly disclosed. We expect attackers could develop a reliable exploit; however, only systems with Windows Media Player 6.4 are vulnerable. Therefore, the likelihood of attackers choosing to write exploits for this vulnerability is lower.
(ActiveX, Office ATL)
Browsing to a malicious website that instantiates an ActiveX control in a malicious manner.
So far, the only ATL-related vulnerability that has been exploited in the real world is msvidctl.dll, addressed by MS09-032. No other ATL vulnerabilities have been exploited. We expect the IE defense-in-depth mitigation combined with the difficulty building custom ATL streams to make these vulnerabilities less likely to be exploited.
Browsing to a website that scripts an ActiveX control in a malicious manner.
This vulnerability was responsibly disclosed. This one is less likely to see a working reliable exploit made publicly available due to the nature of the vulnerability.
An FTP server would need to grant untrusted users access to log into and create a specially-crafted directory. If an attacker were able to successfully exploit this vulnerability, they could execute code in the context of LocalSystem, the service under which the FTP service runs. IIS5 & IIS6 are impacted.
Public exploits are available for this issue.
Internet Information Services 6.0 on Windows Server 2003 is at reduced risk because it was compiled using the /GS compiler option.
Attacker initiates a network connection to a vulnerable workstation or server. LSASS crashes and forces the machine to reboot.
This issue was responsibly disclosed. The impact of this vulnerability is denial-of-service only.
An unprivileged user with logon rights and ability to run arbitrary executables can compromise a system locally.
We rarely see exploits developed for local elevation of privilege vulnerabilities within the first 30 days after release.
Attack details are public but code execution is not possible. We have seen limited exploitation of the spoofing threat.
It is important to factor in your organization’s potential attack surface when deciding in which order to apply the updates. For example, if you grant FTP access to untrusted users, MS09-053 might be the most critical security update for you despite its “Important” rating. If your organization does not have Windows Vista or Windows Server 2008 systems, MS09-050 is less relevant for you because SMBv2 is not supported on earlier systems.
SRD Blog Posts This Month
In addition to this we’ve written several blog entries to help you understand the vulnerabilities more deeply and help you make a more informed risk analysis as you prepare to deploy these updates. Here are the topics covered:
MS09-051: Chen describes how you can know whether a system is vulnerable to this Windows Media Player issue, how the codec download behavior works, and what you can do to protect vulnerable systems. [link]
MS09-050: Mark walks through the history of the exploit landscape for the publicly disclosed SMB remote code execution vulnerability to help you understand the risk to your environment. [link]
MS09-054: Chen explains why there is a FireFox attack vector for this Internet Explorer bulletin, and how you can disable this attack surface if you choose to do so. [link]
MS09-061: Kevin lists the attack vectors for this .NET security bulletin and the various workaround options available. He also explains why we recommend disabling partially-trusted .Net applications and not fully-trusted .NET applications. [link]
MS09-062: Kevin discusses the “kill switches” for GDI+ image format parsers. He shows how you can permanently disable the parsing of, say, TIFF files as a defense-in-depth measure or in response to an unpatched vulnerability. [link]
MS09-056: Maarten outlines the impact of the X.509 / ASN.1 vulnerabilities and highlights some mitigating factors that make them less severe than you might think. [link]
We hope that helps you understand this month’s large security bulletin release. Please email us with any questions.
- Jonathan Ness and Andrew Roths, MSRC Engineering
Special thanks to the entire MSRC Engineering staff for their work on this month’s security bulletins and blogs.
MS09-061 fixes vulnerabilities in the .NET Framework which could allow malicious .NET applications execute arbitrary native code, resulting in remote code execution. This post is intended to help clarify the attack vectors for these vulnerabilities, and to cover recommended workarounds.
Important note: These vulnerabilities in the .NET framework do not affect applications built on the .NET framework – you do not need to recompile any of your applications after installing this update. These vulnerabilities lie only in the .NET framework and make it possible for malicious .NET applications to escape restrictions placed on them.
The attack vectors: So how could these vulnerabilities be exploited? In short, they make it possible for malicious .NET applications to break out of the Code Access Security (CAS) sandbox. There are 3 common scenarios where an attacker could take advantage of this to achieve remote code execution:
· Malicious web page
o A malicious web page could host a malicious XAML Brower Application (XBAP), Silverlight application, or managed plug-in (off by default in IE8).
o Please note that Silverlight 3 is not affected by this bulletin. Users who have upgraded to Silverlight 3 are not vulnerable to attacks from malicious Silverlight applications.
o Note that Internet Explorer is not the only browser impacted as other browsers also support XBAPs.
o If successful, a malicious application could use one of these vulnerabilities to execute arbitrary code on the client in the context of the current logged in user.
· Malicious ASP.NET applications
o Servers which allow untrusted ASP.NET applications to be uploaded and run are vulnerable and should prioritize installing this update.
o Malicious ASP.NET applications could use one of these vulnerabilities to execute arbitrary code on the server in the context of user account of the application pool they are assigned to.
· Malicious .NET applications on network shares
o By default prior to .NET 3.5 SP1, .NET applications on network shares run in the CAS sandbox (they are considered partially trusted).
§ If .NET 3.5 SP1 is installed, then .NET applications on network shares run in full trust by default.
o A malicious .NET application that has been run from a network share could use one of these vulnerabilities to escape the CAS sandbox and execute arbitrary code on the client in the context of the current logged in user.
How to protect computers without the security update:First of all, we recommend installing this update as soon as possible. However, if it is not possible to install the update on all of your computers immediately, there are a couple of workarounds which, when applied together, can help protect your computers in the interim.
1. Disable partially trusted .NET applications
a. Detailed steps are available in the security bulletin: http://www.microsoft.com/technet/security/Bulletin/MS09-061.mspx.
b. This workaround will not affect fully trusted .NET applications, such as .NET applications (EXEs) located on your local hard drive.
c. However, partially trusted applications, such as XBAP, managed plug-ins, ASP.NET applications, and .NET applications on network shares (if you are using a .NET Framework version older than 3.5 SP1), will not be allowed to run.
d. This workaround does not protect against malicious Silverlight applications.
e. Note that this workaround will disable all ASP.NET applications.
2. Temporarily disable Silverlight
a. This workaround is not applicable for Silverlight 3 users as Silverlight 3 is not vulnerable.
b. If you can upgrade to Silverlight 3, we recommend you do that instead of using this workaround.
c. Detailed steps are available in the security bulletin: http://www.microsoft.com/technet/security/Bulletin/MS09-061.mspx.
d. This workaround prevents Silverlight from loading, preventing malicious websites from exploiting this vulnerability, but also preventing non-malicious Silverlight applications from loading.
Why not disable fully trusted .NET applications?There is no need to disable fully trusted .NET applications because they can already do anything in the context of the user account they run in, so arbitrary code execution within that same user account context would not gain an attacker anything.
However, partially trusted .NET applications are restricted by the .NET framework’s CAS feature, and are prevented from performing dangerous actions even if the user account they are running as is allowed to. These partially trusted applications would have something to gain by exploiting one of these vulnerabilities, as they could then perform sensitive actions. Essentially they could elevate from untrusted to trusted applications.
Wrap upI hope you have found this information helpful in understanding the impact of these vulnerabilities, and in how to best protect your computers.
-Kevin Brown, MSRC Engineering
Special thanks to Eugene Bobukh of the MSEC PM team.
Updated October 17, 2009 - updated blog post to clarify that Silverlight 3 is not affected by this bulletin.
Updated August 30, 2010 - Fixed an incorrect link. Thanks Robert for pointing this out!
Updated October 17, 2009 - updated blog post to clarify that Silverlight 3 is not affected by this bulletin.
Updated August 30, 2010 - Fixed an incorrect link. Thanks Robert for pointing this out!
MS09-062 fixes several vulnerabilities in GDI+ related to image parsing. It also includes a feature which allows administrators to disable parsing for each of the different image formats. This feature was publicly released early this year in an optional GDI+ update available on the Microsoft Download Center, but is now being release as part of this bulletin.
After installing this update, you can selectively turn off each of the image parsers in GDI+. This can be helpful in reducing the attack surface of your computer. For example, if you have no need to display TIFF files on a computer, you can disable just the TIFF parsing in GDI+, reducing your attack surface and susceptibility to any future vulnerabilities in the GDI+ TIFF parsing code.
Below is a table of the parsers in GDI+ that can be disabled, and the registry keys used to disable them:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableBMPCodec (DWORD) == 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableGIFCodec (DWORD) == 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisablePNGCodec (DWORD) == 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableICOCodec (DWORD) == 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableTIFFCodec (DWORD) == 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableJPEGCodec (DWORD) == 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles (DWORD) == 1
* The disable switch for WMF and EMF was present before this update (included for completeness)
When one of these disable switches is activated, any attempts to parse a file of that particular format will return an error, just like the parser would normally return an error if the image file was corrupted.
Some applications might assume that parsing will always succeed, particularly when parsing images installed as part of the application. These applications may not gracefully recover when GDI+ returns the error. For this reason, if you want to use this feature to reduce your attack surface, we recommend first disabling the parsers you don’t plan to use, and then testing the applications you use frequently to make sure they are not adversely affected.
Also note that this feature reduces your attack surface by disabling the GDI+ parser for a particular image format, not all parsers for that image format on your computer. Some applications, including Microsoft applications, do not use GDI+ for image parsing. Those other parsers would not be disabled by these registry keys.
We hope you find this feature, and this post, helpful!
Special thanks to Christopher Leung and Ryan Becker from the Windows Sustained Engineering team.
MS09-051 addresses a vulnerability (CVE-2009-0555) in the speech codec of Microsoft Window Media Component.
Users of Windows XP/Windows Vista/Windows Server 2003/Windows Server 2008* are affected by this vulnerability. However, for Win2k users, the story is more complex and we would like to go into more detail in this blog.
*Windows Server 2008 Core installation is not affected.
Are Win2K users affected?
Only in certain circumstances.
By default the vulnerable codec WMSPDMOD.dll is NOT shipped in-box on Win2k. The speech codec is not included in Windows Media Player (WMP) 6.4, which ships with Windows 2000. The optional WMP 7.1 download also does not include it. WMP 9 on the other hand does contain the speech codec. If you’ve installed WMP 9 on your Win2k machine you are affected and we recommend you install this update.
However even if a user only has WMP version 6.4 (default on win2k) or version 7.1, there is a possibility they are also vulnerable. This is due to the automated codec download feature of WMP. The first time a user plays a file requiring a codec that is not present on the system, the player will attempt to download and install it from the Microsoft codec server.
Here is an example. Using WMP 7.1 to play a WMA file that uses Speech codec, you will see the following codec download dialogue in WMP. If you have ever chosen to install the CAB you will have the speech codec WMSPDMOD.dll installed on your machine.
For WMP 6.4 users the player installs a different CAB from the Microsoft’s codec server. The speech codec it provides, WMAVDS32.ax, is affected by this vulnerability too.
How can I protect myself if I am a WMP 6.4/7.1 user on Win2k?
One option is to upgrade your WMP from 6.4/7.1 to WMP 9 and then apply the MS09-051 update.
Another option is to unregister and delete the old vulnerable speech codec if it has already been installed. To do that, follow these steps:
1) Check if WMAVDS32.ax or WMSPDMOD.dll existed in the window’s system32 directory. If files existed, the vulnerable codec has already been installed due to the codec download feature
2) Unregister the old codec
a. For 6.4 users, do regsvr32 /u wmavds32.ax
b. For 7.1 users, do regsvr32 /u wmspdmod.dll
3) Delete these codec files
The side effect of the above steps is that it leaves users unable to play files that use the speech codec.
What if I still need to play these files?
The Microsoft codec server has been updated with the fixed codec. For WMP 6.4/71 users, new versions of the codec will be downloaded and installed if the old codec was not present or was unregistered and deleted and a media file requiring that codec was opened.
Big Thanks to Gavin Thomas and Robert Hensing from MSRC Engineering Team, and Rob Van Schooneveld from WIN GRP SE team.
-Chengyun Chu, MSRC Engineering