SEHOP per-process opt-in support in Windows 7

In a previous blog post we discussed the technical details of Structured Exception Handler Overwrite Protection (SEHOP) which is an exploit mitigation feature that was first introduced in Windows Vista SP1 and Windows Server 2008 RTM. SEHOP prevents attackers from being able to use the Structured Exception Handler (SEH) overwrite exploitation technique when attempting to exploit certain types of software vulnerabilities. SEHOP is enabled by default system-wide on Windows Server 2008 and disabled by default on Windows Vista. These are also the defaults settings in Windows Server 2008 R2 (enabled) and Windows 7 (disabled).

Although some applications have had compatibility problems with SEHOP, the vast majority of applications work without issue. In order to make it possible for compatible applications to take advantage of SEHOP, we have added support in Windows 7 that allows SEHOP to be enabled or disabled on a per-process basis. This setting will override the system default policy when it is used. SEHOP can be enabled for a process by setting the new DisableExceptionChainValidation Image File Execution Option (IFEO) to 0 (or disabled by setting it to 1). For example, SEHOP can be enabled for Internet Explorer on Windows 7 by applying the following registry script*:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\iexplore.exe]

"DisableExceptionChainValidation"=dword:00000000

Users running Windows Vista SP1+ or Windows 7 who would like to enable SEHOP for all applications (which we strongly recommend) can do so by installing the following FixIt:

Enable SEHOP for all applications

If enabling SEHOP for all applications leads to a problem with a specific application, the new IFEO in Windows 7 and Windows Server 2008 R2 can be used to disable SEHOP for just the affected process as described above. Alternatively, you can disable SEHOP for all applications by following the steps described in KB956607. If you cannot enable SEHOP for all applications we strongly recommend enabling SEHOP for all internet facing applications, such as your preferred browser and mail client.

Matt Miller, MSEC Science

* If you are running a 64-bit version of Windows, you will need to set the IFEO under the Wow6432Node portion of the registry which corresponds to the registry hive used by 32-bit applications (e.g. HKLM\Software\Wow6432Node\...)

*Postings are provided "AS IS" with no warranties, and confers no rights.*

Details on the License Logging Service vulnerability

Today, we released MS09-064 which addresses a vulnerability in the License Logging Service.  In this post, we provide some background on the service and the severity of the underlying vulnerability.

Background

License Logging Service (LLS) is a feature that was originally designed to help customers manage licenses for Microsoft server products licensed in the Server Client Access License (CAL) model. See http://support.microsoft.com/kb/824196 for more details.  The service has been removed from the Windows Server product line starting with Windows Server 2008. Of the remaining supported platforms this issue only affects the Windows Server 2000 version of LLS.

Why is the bulletin severity “critical”?

The bulletin is marked as “critical” for several reasons:

·         The service is enabled by default on Windows Server 2000.

·         It is accessible by anonymous network connection.

·         The underlying issue can lead to extensive heap memory corruption.

What are the mitigating factors?

There are two circumstances though that may lower its severity significantly.

First, the most common scenario of LLS feature calls for managing CALs within trusted enterprise environment, which in most cases means that the network access to the server hosting LLS will be limited to the local segment of a network, usually separated from the Internet by a firewall, proxy server, or other barrier.

Second, the issue leads to a memory corruption, which based on our analysis is very difficult to turn into remote code execution.

Technical details

The root cause of the problem is a lack of string verification for the presence of NULL-terminating characters. An unverified string lacking NULL-termination can be passed to a function, which performs following steps:

·         calculate length of the unverified string,

·         allocate buffer for a new string, using the calculated length and the length of some other string,

·         concatenate two strings in the new buffer.

Since the length calculation of the unverified string can run beyond the string buffer (because of missing NULL termination), we may end up with four different scenarios depending on the heap memory layout at the time of execution:

1.     During the string length calculation, code runs beyond string buffer and hits an unallocated memory page, causing read access violation.

2.     During the string length calculation, code finds a NULL terminating character beyond the string buffer, returning an exaggerated length. The terminating character falls at lower address than the memory block allocated for the new string. The “exaggerated” string is concatenated with the other string in the new buffer, causing no memory access exception, because the length of the new buffer was calculated using the “exaggerated” length.

3.     In scenario 2, another thread owning the block of memory containing the NULL-terminating character incorrectly used for the length calculation, changes the content of memory right after the length calculation, but before string concatenation. This causes a new buffer overflow during concatenation, leading to semi-controlled heap corruption and/or write access violation.

4.     In scenario 2, the memory block allocated for the new string includes the NULL-terminating character. The character then gets overwritten during concatenation process, leading to extensive memory copying and causing write access violation.

Scenario 3 relies on a very narrow race condition and thus any attempt to exploit it is likely to be unreliable.  The only scenario leading to a potentially reliable exploit is scenario 4. This leads us to a conclusion that real-life exploitation of this vulnerability will be less likely.

-Greg, MSRC Engineering

Vulnerability in Web Services on Devices (WSD) API

MS09-063 addresses a critical vulnerability (CVE-2009-2512) in the Web Services on Devices (WSD) API. Web Services on Devices allows a computer to discover and access a remote device and its associated services across a network. It supports device discovery, description, control, and eventing.

The WSD API functionality is implemented in the WSDApi.dll module in Windows, and is used by several services and applications. The API is also documented on MSDN for 3^rd party developers to use. Therefore, a comprehensive list of services and application that are vulnerable to this issue is hard to define, but here are some examples:

·         Print Spooler service

·         Function Discovery Resource Publication service

·         Function Discovery Provider Host service

·         Windows Network Projector

There are mitigating factors that limit the scenarios where the vulnerability can be exploited. We will describe the vulnerability and mitigating factors in more detail in this blog post.

What is the issue?

A long header value within a WSD message can lead to stack corruption within the process hosting WSDApi.dll. This can cause the service or application to crash, or could lead to Remote Code Execution. To be clear, the vulnerability is in the Windows module used to interact with devices that support Web Services on Devices, and does not affect the devices themselves.

What platforms are affected?

Windows Vista and Windows Server 2008 are affected. WSDAPI was introduced in Windows Vista and hence earlier versions of Windows are not vulnerable.

Only systems with the WSD TCP ports active and listening are vulnerable to the most likely attack vector. Whether a system has WSD ports active and listening depends on the system configuration and applications that are installed.

What are the attack vectors?

By default, WSDAPI will listen on TCP ports 5357 and 5358. The Windows Firewall will allow messages in to these ports if the interface firewall profile is anything other than Public. This means under non-Public profiles (e.g. Private or Domain) the vulnerability can be reached by remote, unauthenticated users.

For an attacker to be able to trigger the vulnerability on a target, they need to know the WSD Address value for the target, which is a UUID (Universally Unique Identifier). This value is automatically sent in broadcast UDP messages to port 3702 (WS-Discovery) in an effort to discover devices that support WSD. Being broadcast UDP the message will only be visible to attackers on the same subnet. Attackers on other subnets, or on the Internet, will not be able to launch attacks against distant targets using this approach.

A system could also be exploited by a malicious device which responds to a client computer using WSDAPI. It is possible for the user to manually enter the URL of a device to connect to, in which case the device could respond with a malformed message and trigger the vulnerability. This requires user-interaction and social engineering, however.

Mitigating factors

As explained above, the most common exploit scenario requires that the attacker is on the same subnet as the target system in order for the target’s WSD Address to be discovered.

The default Windows Firewall rules limit inbound WSD messages to sources on the local subnet for Private and Domain profiles. The Public firewall profile blocks WSD messages completely.

If WSD functionality is not needed, the security bulletin provides information on using the Windows Firewall to block the inbound and outbound ports used to trigger this vulnerability.

I’d like to thank Rob Hain and Dan Driscoll from the WSD team, and Kevin Brown from MSRC Engineering for their work on this issue.

Font Directory Entry Parsing Vulnerability In win32k.sys

MS09-065 addresses a vulnerability (CVE-2009-2514) in the font parsing subsystem of win32k.sys.  If not addressed, this vulnerability could allow an attacker to bluescreen (DoS) the machine (best case scenario) or run code of his/her choice, possibly in the context of the kernel (worst case scenario). 

In this blog entry, I'll attempt to answer a few questions regarding the vulnerability addressed in this month’s win32k.sys security update:

What is the issue?

An integer-wrapping vulnerability exists in the font parsing subsystem within win32k.sys, which is responsible for constructing a table of directory entries.  The integer wrap can occur when adding a directory entry’s’ offset and size members, which could lead to improper memory access in subsequent code.  This improper memory access would commonly be observed in the form of a Read Access Violation.

The severity rating of critical was chosen since the vulnerable code is exposed through Internet Explorer and can be exercised without user interaction/notification.  It has also been given an Exploitability Index rating of 1.

What platforms are affected?

Users of Windows 2000, Windows XP, and Windows Server 2003 are affected by this vulnerability.  Windows Vista, Windows 7, Windows Server 2008, and Windows 2008 R2 users are not affected.

What are the attack vectors?

Remote attack vectors (worst case scenario is Remote code Execution):

-    Malicious fonts (TTF’s) delivered within .eot files hosted on malicious web sites which are rendered in all versions of Internet Explorer by default.

-    Malicious office documents e-mailed to victims with social engineering to entice the victim to open the document which contains a malformed embedded font which would then be rendered upon opening the Office document (PowerPoint and Word documents are the most likely attack vectors).

Local attack vectors (worst case scenario is Local Elevation of Privilege):

-    Malicious fonts (TTF’s) delivered to win32k.sys by an authenticated user in a multi-user environment (Terminal Services (TS)) scenario. Such scenarios might abuse AddFontResource() to achieve this.

How do I protect myself?

The best option for protecting against this vulnerability is to apply the update for MS09-065.

If you are unable to apply the update, another option is to disable support for parsing/loading embedded fonts in IE.  The side effect of this approach is that it will cause web sites which make use of embedded font technology to fail to render properly.  The steps involved in disabling support for parsing embedded fonts in IE are as follows:

Interactive

·         Launch Internet Explorer

·         On the ‘Tools’ Menu select ‘Internet Options’.

·         Click the ‘Security’ Tab.

·         To change the setting for the ‘Internet’ zone select ‘Internet’ and press the ‘Custom Level’ button.

·         Scroll down to the ‘Downloads’ section and select ‘Prompt’ or ‘Disable’ for the ‘Font Download’ security setting.

·         Press OK to close the ‘Security Settings’ dialog box.

·         Press OK to close the ‘Internet Options’ dialog box. 

Group Policy

NOTE:  The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit or an entire domain.  It is assumed that the reader will know how to deploy the steps below for their particular environment.

·         Open the group policy management and configure it to work with the appropriate group policy object (i.e. local machine, OU or domain GPO).

·         Navigate to the following node:

o    User Configuration -> Windows Settings -> Internet Explorer Maintenance -> Security.

·         Double click ‘Security Zones and Content Rating’.

·         On the ‘Security Zones and Content Rating’ dialog box select ‘Import the current security zones and privacy settings’ and then click the ‘Modify settings’ button.

·         NOTE:  This will create a group policy for Internet Explorer based on the settings of the currently logged in user.

·         On the ‘Internet Properties’ dialog box ensure the ‘Internet’ zone is selected and then press ‘custom level’.

·         Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.

·         Press OK to return to the ‘Internet Properties’ dialog box.

·         On the “Internet Properties’ dialog box select the ‘Local Intranet’ zone and then press ‘custom level’.

·         Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.

·         Press OK to return to the ‘Internet Properties’ dialog box.

·         Press OK to return to the ‘Security Zones and Content Ratings’ dialog box.

·         Press OK to return to the group policy management console.

·         Refresh the group policy on all machines or wait for the next scheduled group policy refresh interval for the settings to take effect.

Managed Deployment Script

This security setting can be manually entered into the registry by creating a registry script and importing it either by double clicking it or running regedit.exe as part of a logon or machine startup script.  For managed deployments Regedit.exe can be used to import a registry script silently with the ‘-s’ switch.  For more information on regedit command line switches refer to: http://support.microsoft.com/kb/q82821/

To set this setting to ‘Prompt’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00

; Zone 1 is the local intranet zone

; 1604 is the Font download policy

; dword:00000001 sets the policy to prompt

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]

"1604"=dword:00000001

; Zone 3 is the internet zone

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]

"1604"=dword:00000001

To set this setting to ‘Disable’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00

; Zone 1 is the local intranet zone

; 1604 is the Font download policy

; dword:00000003 sets the policy to disable

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]

"1604"=dword:00000003

; Zone 3 is the internet zone

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]

"1604"=dword:00000003

Big thanks to Robert Hensing from the MSRC Engineering Team for his work on defensive workarounds for this issue as well as to Andrew Roths from the MSRC Engineering Team.

-Brian Cavenah, MSRC Engineering

Announcing the release of the Enhanced Mitigation Evaluation Toolkit

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.

Supported Mitigations

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.

SEHOP

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. 

Dynamic DEP

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.

 NULL page allocation

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 spray allocation

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

A Note about Application Compatibility

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.

Feedback

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 switech@microsoft.com .

Special thanks to Matt Miller for his assistance with EMET.

-  Fermin J. Serna and Andrew Roths, MSRC Engineering

Assessing the risk of the October security bulletins

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.

Prioritization Criteria

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.

Prioritization Table

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-056: Addressing the X.509 CryptoAPI ASN.1 security vulnerabilities

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 “2.5.4.3” 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

MS09-051: A note on the affected platforms

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

MS09-050: Exploit timeline for the SMB2 RCE vulnerability

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.

Initial disclosure

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.

Exploit timeline

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.

Current situation

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.

MS09-054: Extra info on the attack surface for the IE security bulletin

Via this plug-in it is possible to launch XBAP, and reach this vulnerability, from within Firefox.

MS09-061: More information about the .NET security bulletin

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/MS06-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/MS06-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 up
I 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.

New attack surface reduction feature in GDI+

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:

* 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!

-Kevin Brown, MSRC Engineering

Special thanks to Christopher Leung and Ryan Becker from the Windows Sustained Engineering team.

Update on the SMB vulnerability situation

We’d like to give everyone an update on the situation surrounding the new Microsoft Server Message Block Version 2 (SMBv2) vulnerability affecting Windows Vista and Windows Server 2008.

• Easy way to disable SMBv2
• First exploit for code execution released to small number of companies
• Mitigations that help prevent attacks
• Status of fixes

Easy way to disable SMBv2

Until the security update is released, the best way to protect systems from this vulnerability is to disable support for version 2 of the SMB protocol. The security advisory was updated yesterday with a link to the Microsoft Fix It package that disables SMBv2 and then stops and starts the Server service. (This initial Fix It might prompt you to also restart the Browser service.)  You can also click here:

To revert the workaround, and re-enable SMBv2, you can click here:

Disabling SMBv2 may slow down SMB connections between Windows Vista and Windows Server 2008 machines.

First exploit for code execution released to small number of companies

We are not aware of any in-the-wild exploits or any real-world attacks. 

However, we are aware of exploit code developed by Immunity Inc. and released to customers who subscribe to the CANVAS Early Updates program. We have analyzed the code ourselves and can confirm that it works reliably against 32-bit Windows Vista and Windows Server 2008 systems. The exploit gains complete control of the targeted system and can be launched by an unauthenticated user.

The exploit can be detected by intrusion detection systems (IDS) and firewalls that have signatures for the vulnerability being targeted (CVE-2009-3103).

This exploit code from Immunity is only available to a small group of companies and organizations who will use it to determine the risk to their own networks and systems, or those of their customers. (We are aware that other groups are actively working on exploit code which is likely to be made public when it is completed).

Mitigations that help prevent attacks

There are a number of mitigating factors that could aid in preventing attacks such as:

• Enterprise customers can disable SMBv2 using a simple registry script or the Fix It described above. Disabling SMBv2 prevents the vulnerable code from being reached.
• Consumers (not part of an enterprise network) are protected by the on-by-default firewall included in Windows Vista:
  • The on-by-default Windows firewall protects vulnerable systems
  • The on-by-default Windows firewall allows packets through only if a user explicitly shares a folder or printer.
  • When a Windows Vista user chooses the ‘Public’ firewall setting, the firewall will block packets even if a folder or printer has been shared.

Status of fixes

Even with the above mitigations, we’re not slowing down our investigation, and are working on an update that can be delivered for all customers. The product team has built packages and are hard-at-work testing now to ensure quality. It takes more testing than you might think to release a quality update.  For this update, the product team has so far already completed over 10,000 separate test cases in their regression testing.  They are now in stress testing, 3rd-party application testing, and fuzzing.  We'd sure like to complete all that testing before the update needs to be released.  We are keeping a close eye on the changing landscape and balancing this against the remaining test actions to determine the best ship schedule to bring a quality update to customers.

- Mark Wodrich and Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

OffVis updated, Office file format training video created

In July, we released a beta Office file format viewer application called OffVis as a downloadable tool. We are pleased today to announce an updated version of OffVis and a 30 minute training video to help you understand the legacy Office binary file format.

OffVis 1.1

The community response to the release of the OffVis tool on July 31st has been great. Thank you for the feedback! We are releasing this new version 1.1 of OffVis in response to that feedback. This release introduces several requested new features and fixes bugs. Here are the highlights:

• Now requires only .Net Framework 2.0 (1.0 Beta required 3.5, preventing some people from using it)
• Addressed OLESS loading logic bugs that was leading to false negatives (detection logic misses)
• Added the detection logic for several more Word and PowerPoint CVE’s, detecting files sent in by customers.
• Added a “Reallocate” feature (under Tools menu) that makes some corrupted files parse-able
• Clarified some error message text
• Prevented OffVis from appearing in a saved location off-screen
• Cleared highlighting after the parser changes
• Removed limit on number of parsing notes displayed

Here is the new list of detected CVE’s:

Please email us any undetected malicious samples that exploit vulnerabilities for code execution. We will evaluate whether we can add detection that can help everyone detect malicious files.

You can learn more about OffVis from our original blog post about the tool or an article written by Russ McRee in the ISSA journal.  You can download the tool at http://go.microsoft.com/fwlink/?LinkId=158791

Office legacy binary file format training video

Bruce Dang and Nick Finco from the MSRC Engineering team put together a 30 minute training that describes the legacy binary Office file format and describes how to parse it. Our Bluehat team agreed to record it and host it on the Bluehat technet site. You can view the video at http://research.microsoft.com/en-us/UM/redmond/events/BH09/lecture.htm. In less than thirty minutes, they provide in-depth technical guidance, including full-screen demos. This video is geared toward security analysts, virus researchers, IDS signature authors, and security professionals.

Direct video link: http://research.microsoft.com/en-us/UM/redmond/events/BH09/lecture.htm

Summary

Thanks to the many people who made this possible. Kevin Brown and Dan Beenfeldt for the development of OffVis. Robert Hensing and Bruce Dang for tireless hours testing the tool and building and refining detection logic. The MSRC Engineering team for technical investigations leading to these detections. Bruce and Nick Finco for recording the video. Damian Hasse and Matt Thomlinson for the support to release this tool. Celene Temkin and the Bluehat team for the logistical magic to make the video happen. Thanks everybody!

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

AutoPlay Windows 7 behavior backported

Back in April we talked about the Windows 7 improvements in AutoPlay that disables certain functionality which has been abused by malware (like Conficker). We also mentioned that these changes will be backported to down level platforms. On August 25^th this functionality was made available for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008, please visit the following KB article for more information and how to download the updates http://support.microsoft.com/kb/971029

Thanks to Dave Midturi (from MSRC) and Ugo Enyioha (from Windows Sustained Engineering team) for helping on this work.

Thanks,

Damian Hasse – MSRC Engineering

*Postings are provided "AS IS" with no warranties, and confers no rights.*