For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications.  This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited.  By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products.  In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.

Below is a screenshot of the tool, which features a brand new interface as part of this release.

The installation package for EMET v2.0 includes a detailed user guide.  A copy can also be found at the bottom of this post.  It gives an overview of the tool, instructions on how to use it, answers to frequently asked questions, and caveats about the mitigations that users should be aware of.  Please be sure to read the guide before using the tool.

Additionally, the BlueHat team has helped us put together a training video on EMET v2.0.  The video gives an even more in-depth look at some of the security mitigations offered by the tool.  You can watch the video online here.

To get more information on how this FREE tool can help you take advantage of the protections it offers please refer to our previous blog post announcing the upcoming release.  That post also gives a rundown of all the changes that are new with the 2.0 version.

As always, we welcome your feedback and would like to hear more about your experiences with EMET.  Please feel free to e-mail us at switech@microsoft.com

- Andrew Roths and Fermin J. Serna

Today we wanted to provide an update by answering several questions we have received from customers and addressing common misperceptions about the risk posed by this class of vulnerability.

• The user experience of the exploit in progress
• The dangers of untrusted, Internet-zone WebDAV
• Enabling the CWDIllegalInDllSearch protection tool

The user experience of the exploit in progress

This class of vulnerabilities does not enable a “driveby” or “browse-and-get-owned” 0-click attack. To be exploited, a victim would need to browse to a malicious WebDAV server or a malicious SMB server and double-click a file in the Windows Explorer window that the malicious server displays. Let’s walk through an example of what an attack might look like:

First, the user browses to a malicious website:

The website would then attempt to display a new Windows Explorer window that points to a malicious WebDAV or SMB share. On systems running Protected Mode, Internet Explorer will require user consent to launch Windows Explorer, using a security warning like the one below. Protected Mode is enabled by default for Internet Explorer on Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

After the user allows Windows Explorer to launch (or if they have previously requested that Internet Explorer no longer display this warning), the user will be presented with a Windows Explorer dialog that is likely to look like the one below:

At this point, if the user were to double-click the data file on the share, the affected application could potentially run attacker code that is separately hosted on the same WebDAV server.

The dangers of untrusted, Internet-zone WebDAV

As described above, this class of vulnerabilities could allow malicious code to run if an attacker can convince a victim to do the following:

• Browse to a malicious, untrusted WebDAV server in the Internet Zone; and
• Double-click a file that appears by its extension and icon to be safe

Unfortunately, based on attack patterns we have seen in recent years, we believe it is no longer safe to browse to a malicious, untrusted WebDAV server in the Internet Zone and double-click on any type of files. Attackers are clever, substituting dangerous file icons with safe, trusted file icons. They have even recently begun obfuscating the filename based on character encoding tricks (such as right-to-left character encoding). Their goal is to entice unsuspecting users into double-clicking on a malicious executable. With or without this new remote vector to the DLL Preloading issue, it’s very hard to make a trust decision given the amount of control an attacker has over the malicious WebDAV server browsing experience. We recommend users only double-click on file icons from WebDAV shares known to be trusted, safe, and not under the control of a malicious attacker.

Enabling the CWDIllegalInDllSearch protection tool

We have received several questions regarding the best way to enable the protection tool released on the Microsoft Download Center last week.

First, you should know that downloading and installing the tool alone will not protect a workstation from vulnerable applications. It ships “off-by-default” and must be enabled either system-wide or for specific applications. After releasing this tool, we received a number of questions on how best to deploy it. We have now updated the KB article to address them. We encourage you to review the updated knowledge base article 2264107.

Secondly, customers have asked us to recommend the best setting among the three choices. We recommend one of two settings, depending on the specific risk about which you are concerned.

• Setting the CWDIllegalInDllSearch regkey to 2 system-wide will completely block any network-based attack. We’ve built an automated Fix-it solution to enable that. You can click the Fix-it graphic below on systems that have already installed the tool to set CWDIllegalInDllSearch = 2, blocking DLL loads from the current working directory for both WebDAV and SMB except in cases where the application is run from a WebDAV or SMB share.

Note: The Fix-it itself does not install the workaround tool. You’ll need to separately download and install the tool beforehand.

• To instead completely block all DLL-preloading attack vectors, including the threat of malicious files on a USB thumb drive or files arriving via email as a ZIP attachment, set CWDIllegalInDllSearch to 0xFFFFFFFF. This will address any DLL preloading vulnerabilities that may exist in applications running on your system. However, it may have some unintended consequences for applications that require this behavior, so we do recommend thorough testing.

This section option can be enabled by following these steps:

• Install the tool from KB2264107.
• Log on to your computer as an administrator.
• Open Registry Editor.
• Locate and then click the following registry subkey: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager
• Right-click Session Manager, point to New, and then click Dword Value.
• Type CWDIllegalInDllSearch, and then click Modify.
• In the Value data box, type 0xFFFFFFFF, and then click OK.

While the impact of the above change seems to be low, a reader of this blog wrote in that he experienced a compatibility issue with the Outlook 2002 address book. If you experience issues such as this, they can be mitigated by setting a special policy for the affected binaries that overrides the default CWDIllegalInDllSearch. The following steps show how to do this for OUTLOOK.EXE:

• Log on to your computer as an administrator.
• Open Registry Editor.
• Locate and then click the following registry subkey: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionImage File Execution OptionsOUTLOOK.EXE
• If a key with the application binary name does not exist, then you will have to create one.
• Right-click OUTLOOK.EXE, point to New, and then click Dword Value.
• Type CWDIllegalInDllSearch,and then click Modify.
• In the Value data box, type 2, and then click OK.

This will still prevent OUTLOOK.EXE from loading DLL’s from a remote network share or WebDAV location, but it does not remove CWD from the library search path for this application altogether. This process can be repeated for all other applications that may no longer work correctly. As discussed, we don’t believe this will be common, but we do recommend testing.

Thanks for your interest in this issue. Please send questions in to switech@microsoft.com.

Jonathan Ness, MSRC Engineering
Maarten Van Horenbeeck, MSRC Program Manager

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

• Background about the vulnerability
• Information to help you make a risk assessment for your environment
• An optional binary update you can install to protect your systems
• Guidance for developers
• What Microsoft is doing

The vulnerability

When an application loads a DLL without specifying a fully qualified path name, Windows will attempt to locate the DLL by searching a defined set of directories. We have discussed the DLL search path on this blog and it has also been explained well on David LeBlanc’s blog. For the sake of this issue, its sufficient to say that if an attacker can cause an application to LoadLibrary() while the application’s current directory is set to an attacker-controlled directory, the application will run the attacker's code. Development best practices state that applications should call SetDllDirectory with a blank path before calling LoadLibrary(“foo.dll”) to ensure that foo.dll is not loaded from the current directory. We are investigating whether any of our own applications are affected by this class of vulnerability so that we can take appropriate action to protect customers.

Making a risk assessment for your environment

The most likely exploit scenario involves an attacker convincing the victim to open a file hosted on an attacker-controlled SMB or WebDAV share. The file itself would not necessarily be malicious or malformed. The key is that the file is loaded from a location where an attacker can also place a malicious DLL with the same name as a DLL the vulnerable application loads.

If a perimeter firewall prevents a system from making outbound SMB or WebDAV connections to attacker-controlled locations, this issue poses little risk. An attack cannot be automatically launched through email or web browsing attack vectors; a user must choose to open a file. However we recognize that users will often open trusted filetypes. We continue to recommend that all outbound SMB is filtered at the perimeter firewall. In addition, the security advisory recommends disabling the WebDAV client service on workstations to prevent outbound WebDAV connections.

A tool you can use to protect your systems

Another option for protecting your systems is to deploy a tool that can help prevent exploitation of this issue. Knowledge Base article 2264107 offers for download a tool that allows customers to selectively change the library loading behavior, either system-wide or for specific applications.

Customers can set the following two registry keys: 

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
 Session ManagerCWDIllegalInDllSearch
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersion
 Image File Execution Optionsbinaryname.exeCWDIllegalInDllSearch

Setting the first key will define the system-wide behavior, whereas the second key will set the behavior for one particular application. Note that this is an Image File Execution Option (IFEO), and thus will be valid for all binaries with that same name on the system.

The values for these keys have slightly different effects, depending on from where the application is started.

Scenario 1: The application is started from a local folder, such as C:Program Files

Scenario 2: The application is started from a remote folder, such as \remoteshare

Scenario 3: The application is started from a WebDAV folder, such as http://remote/share

How can developers address these issues?

Microsoft recommends that developers clearly define from where they intend to load specific libraries. This was documented in the specific LoadLibrary application programming interface documentation on MSDN. However, we recognize that this guidance may not always have been very clear. We recently published an MSDN article, “Dynamic-Link Library Security,” that provides specific guidance to developers on how to load these libraries securely.

While there are several affected situations, described in detail in the above MSDN article, our general recommendations are:

• Where possible, use a fully qualified path name when loading a library;
• Remove the current directory from the search path by using SetDLLDirectory;
• Do not use SearchPath to locate a library. SearchPath was not intended to look for libraries to be loaded into the application process space, and uses an insecure search order;
• Do not attempt to load libraries purely to identify the version of Windows. Instead, use GetVersionEx or a similar function offered by the Windows API.

We’ve also recently drafted additional guidance to help developers understand this issue. You can find that developer guidance attached to the blog post. 

What Microsoft is doing

Loading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some applications require the ability to load libraries from the current working directory. Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not make this mistake in the future.

Microsoft is also conducting a thorough investigation into how this new vector may affect Microsoft products.  As always, if we find this issue affects any of our products, we will address them appropriately.

We hope this blog helps address any questions you may have. Thanks to Mark Debenham, Anoop KV, Hari Pulapaka, Dou Kaya, Gov Maharaj, David LeBlanc, and Michael Howard for their work on this issue.

Cheers,

Jonathan Ness, MSRC Engineering
Maarten Van Horenbeeck, MSRC Program Manager

Thanks to all of MSRC Engineering for their work on these cases.

- Jonathan Ness, MSRC Engineering

As mentioned in the bulletin, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows 2008 R2 systems are not vulnerable to unauthenticated attackers by default. (Only if password-based sharing was disabled would one of these systems be vulnerable.) In the most common scenarios, and on these versions of Windows by default, the attacker would therefore need to be authenticated.

Vulnerability details

In order to exploit CVE-2010-2550, the attacker must have read permission on a SMB share on the target system. This implies that the attacker is authenticated, or that the target allows anonymous access to network shares (this is a default configuration only on Windows XP with later platforms requiring authentication by default)

By sending a specially crafted SMB request to the target, an attacker with read access could cause a kernel pool block to be overrun. This is due to an attacker-provided length being used as the size value in an allocation call. If an attacker specifies a small size value, the system will later write data to this buffer, which will corrupt the adjacent pool block(s). The data used in the overwrite comes from the disk or file system on the target machine.

Exploitability details

Assuming the attacker is able to trigger the vulnerability, there are some factors that make reliable exploitation difficult:

• Windows 7 and Windows 2008 R2 systems have mitigations in the kernel to prevent pool overrun exploitation which will make the remote attack even more difficult (as discussed here http://blogs.technet.com/b/srd/archive/2009/05/26/safe-unlinking-in-the-kernel-pool.aspx)
• The data that will be written to the kernel pool block is not attacker-controlled and instead comes from the disk or file system on the target machine. Finding data that contains useful values in the right location for an attacker’s purposes will be difficult in a remote attack scenario. A local attacker has more control and might be able to allocate memory on the system in a way that allows corrupted pointers in the pool to be leveraged for local elevation of privilege (EOP).
• Failed exploitation attempts will result in a system crash (bugcheck), so the attacker will only get one attempt (per boot) to exploit the vulnerability.

For these reasons we think it will be difficult to build reliable RCE exploits for this vulnerability, and remote DoS attacks are much more likely. A local EOP exploit is possible. The risk of a worm spreading using this vulnerability is very low.

Thanks to the following people for their hard work on this issue:

• Bruce Dang, MSRC Engineering
• Dustin Childs, MSRC
• Kowshik Jaganathan, Hassan Sultan, Vivek Jain , Felix Coifman, Geoffrey Antos , Purujit Saha, Faraz Qadri, Shiraj Kashani and Anindya Das from the Windows Sustained Engineering
• Shivani Sharma, Ather Haleem, Gary Shang, David Kruse and Greg Kramer from the Windows Core SMB
• Julien Vanegue, MSEC Pentest

Thanks to Fermin J. Serna and Andrew Roths for contributing to this blog post.

- Mark Wodrich, MSRC Engineering

TLS and SSL did not effectively guarantee this authenticity, and as a result, the underlying protocol would need to ensure that the renegotiated session is still with the same peer, something the protocol is often ill prepared for. An attacker with the ability to intercept traffic (for instance through an ARP spoofing attack, or DNS cache poisoning) could execute a man-in-the-middle attack, intercept a TLS renegotiation attempt, and partially pose as the authenticated client.

By cleverly manipulating the protocol, the researchers identified that as man-in-the-middle, they could keep the client-end of the connection stalled, start up their own renegotiation with the server, and submit data. Once the server received it, they would restart the renegotiation, and pass the server’s renegotiation attempt back to the client as if nothing happened. While an attacker cannot use this to change or read encrypted information, it can be leveraged to prepend data to a secure connection.

Some protocols are more affected than others. HTTPS for instance, is affected. An attacker can send an HTTPS request from the client to the server, and by splicing the request can have the actual client send through the authentication cookie. The server will read the request issued by the attacker, and attribute it to the authenticated client.

The risk to most Microsoft customers, overall, is limited. While the TLS/SSL implementations for all vendors are affected, overall risk to our customers is limited. In order to exploit this vulnerability, the attacker needs to abuse TLS renegotiation already taking place between both peers.  Internet Information Services (IIS) 6 and 7, do not allow clients to initiate TLS renegotiation, removing the attacker’s ability to induce a vulnerable scenario. These servers will only start up renegotiation themselves when they are configured to  ‘accept’ certificate based mutual authentication. This is a non-default scenario. In addition, our team found a number of other reasons why this issue would be difficult to exploit. We published more detail on our overall risk assessment in this February blog entry.

It is important to note that this is still potentially a significant issue for certain deployments, and the update should be installed. In particular, the vulnerability may affect other, non-HTTP protocols that are less well understood. When the vulnerability was identified, Microsoft worked through the Industry Consortium for Advancement of Security on the Internet (ICASI) to ensure that we had a TLS-layer fix which is compatible with third-party TLS implementations.

The result of that collaboration, and hard work by many other security developers in the IETF TLS working group, led to the publication of RFC 5746, the TLS Renegotiation Indication Extension. This new standard, co-authored by Nasko Oskov in our Windows security engineering team, addresses the vulnerability by defining a TLS extension that cryptographically binds renegotiations to their initial TLS connection. With this fix installed, the TLS endpoint itself can validate whether the data sent still belongs to the same initial connection. There is no longer any requirement for the encapsulated protocol to do so.

In order for a connection to be fully protected, both client and server need to have a TLS implementation that is RFC 5746 compliant. As of today, we’re happy to announce that Microsoft customers have an update available that will deploy this new functionality. We also know many other vendors have either released or are in the process of releasing support for this extension.

We understand that administrators may have a need to require clients to have the update in order to connect to high-security applications. A registry key is available, documented in KB 980436, which allows the administrator to place a system in “Compatible” or “Strict” mode. In compatible mode, the default setting, the client will enable the use of this TLS extension, but not enforce it. A client connecting without the security update will still be able to successfully connect with peers that do not. In strict mode, both peers will require the standard in order to successfully connect.

The following diagram displays this in more detail:

Acknowledgements

Thanks to the following for their work on this issue and feedback on the blog:

Nasko Oskov from Windows Security Engineering
Gavin Thomas and Robert Hensing from MSRC Engineering
Manoj Thakur and Chunlin Shi from Windows Sustained Engineering

Cheers,
-Maarten Van Horenbeeck, MSRC Program Manager

This update also includes several “Defense in Depth” measures that correct potential integer overflows in unrealistic scenarios. In this blog post we are going to walk you through these vulnerabilities to help explain the technical reasoning behind the DiD rating.

In order to understand these issues we first need to understand the source code involved. The win32k.sys component, among other things, is responsible for handling and forwarding windows messages. Before handling or forwarding them, win32k.sys will validate the messages and their parameters: probing, fetching from user mode, validating sizes, pointers, etc…

While handling a certain type of request, and before forwarding it to the top windows on the desktop, several potential integer overflows can happen that would bypass the before mentioned checks. All these are similar to the one that we will focus on:

             case DBT_DEVTYP_PORT:

                pPortW = (PDEV_BROADCAST_PORT_W)lParam;

                if ((1+wcslen(pPortW->dbcp_name))*sizeof(WCHAR) + FIELD_OFFSET(DEV_BROADCAST_PORT_W, dbcp_name) > cbSize) {

                    MSGERRORCLEANUP(0);

                }

                break;

An attacker could control the value of pPortW->dbcp_name, which is already probed and captured locally in kernel space.

On 32 bit systems an integer overflow can happen if wcslen() returns more than 2^31¹.  This would require having a 2^32¹ byte string captured in kernel mode plus the same one in user mode, 2^33 in total. This is not possible on current 32bit systems since with this 32bit range you can only have 2^32 bytes of virtual memory per process shared by user mode and kernel mode

However, that still leaves 64 bit systems.  In order to see if this could be exploitable on 64 bit system we will go to the assembly level.

                0:000> u fffff97f`ff07474c

                fffff97f`ff07474c 488d7b0c        lea     rdi,[rbx+0Ch]

                fffff97f`ff074750 33c0                xor     eax,eax

                fffff97f`ff074752 4883c9ff         or      rcx,0FFFFFFFFFFFFFFFFh

                fffff97f`ff074756 66f2af             repne scas word ptr [rdi] <- inlined wcslen

                fffff97f`ff074759 48f7d1            not     rcx <- rcx contains the length

                fffff97f`ff07475c 488d4c090c   lea     rcx,[rcx+rcx+0Ch] <- this does not overflow unless you have a really big (length ~ 2^63 )

                fffff97f`ff074761 493bcc          cmp     rcx,r12 <- compare against cbSize…

                fffff97f`ff074764 7609            jbe     fffff97f`ff07476f

                0:000>

The comparison from the above source code is up-casted on 64 bit systems. Again, the attacker needs a really big string in user space (plus the local copy at kernel space).  That’s 2^65 bytes of data and is not possible on current 64bit systems either.

So, why are we fixing it? If there is a future recompilation or source change and the comparison is down-casted to 32 bits this could potentially be exploitable on 64 bit systems. Adding that to the fact that we have fixes in the close area makes this a worthy effort.

-Fermin J. Serna, MSRC Engineering

¹ These two values are rounded up.  Technically the value that must be bypassed is a few bytes less.  However, this does not change the overall argument as the size of the string is too large to be allocated on the system.

This vulnerability is present in the code that validates client certificate requests sent by the server. An attacker could set up a malicious TLS or SSL-enabled server, and convince a user to connect to it using a Windows client application.

A malicious server could then respond with a specifically crafted message in a way that induces heap corruption on the client, leading to a crash of the Local Security Authority Subsystem Service (LSASS). Theoretically, this is an exploitable condition, and the attacker could then arbitrary code as LocalSystem.

A detailed investigation by our team, however, has indicated that the attacker has very little control over what is written to the heap. This vulnerability has an Exploitability Index rating of 2, which indicates we believe it’s unlikely that reliable exploit code will be published within 30 days.

We do recommend customers to install this update, especially because it is difficult to build on-the-wire mitigation against this issue. In the TLS handshake protocol, the client certificate is usually requested inside the existing encrypted TLS channel. This makes it difficult for firewalls and intrusion prevention systems to successfully detect and block an attack.

Acknowledgements

Thanks to Mark Wodrich and Bruce Dang from the MSRC Engineering team for their contribution to this blog post.

Cheers,
-Maarten Van Horenbeeck, MSRC Program Manager

In October 2009, we released a tool on this blog called EMET that provides users with the ability to deploy security mitigation technologies to arbitrary applications. Doing so helps to prevent vulnerabilities in those applications (especially line of business and 3^rd party apps) from successfully being exploited. It also responds to requests from customers to help manage risk in older, legacy products while they are in the process of transitioning over to modern, more secure products. Beyond that it makes it easy for customers to try mitigations against any software and provide feedback on their experience to the vendor.

EMET sparked customer interest and based on the feedback that we received, we decided to release version 2 that includes more mitigations, a better interface, and a more robust infrastructure compared to the earlier version of EMET.  

Our aim with this version is to provide an innovative solution that helps customers manage risk and minimize disruption in their environment. This is reflected in our goals for the release:

• Leverage the tool for vulnerabilities under active exploitation to help customers prevent themselves from being exploited.
• Give customers the ability to use newer mitigation technologies to help protect older applications that cannot be recompiled to opt into them.
• Provide a central interface to make it easier for users to manage both system and application mitigations.

These new goals increase the scope of EMET significantly from version 1. As a result, the old definition of EMET (Enhanced Mitigation Evaluation Toolkit) is no longer a good fit. With version 2, we are changing the EMET acronym to stand for Enhanced Mitigation Experience Toolkit to reflect this.

While EMET can be used by anybody, it is primarily targeted at protecting applications on machines that are at high risk for attack. Good examples include line of business applications on backend servers and browsers on the desktops of corporate executives. These are scenarios where an application compromise could be particularly damaging. 

As with most software, deploying this tool will likely involve an individual, such as an IT professional, testing to ensure that EMET works smoothly with applications where the mitigations are desired (like line of business applications and 3^rd party products). Once in place, EMET will be transparent to the end user.

That said of course EMET is also ideal for any security savvy user wishing to harden the apps they use against possible exploitation. Developers and security professionals can also use it as a convenient way to try out security mitigations.

During the Aurora outbreak back in January 2010, Data Execution Prevention and Address Space Layout Randomization (two types of mitigation technologies) played an important in blocking known attacks.  You can find more information on these SRD blog posts IE Vulnerability Risk Accessment and DEP and the New IE Vulnerability

The new version of EMET will include a total of six mitigations. Four of them are from the original EMET, while Export Address Table Access Filtering and Mandatory Address Space Layout Randomization are new for version 2. Here are some more details on the mitigations:

DEP has been available since Windows XP.  However, current configuration options don’t allow applications to be opted in on an individual basis unless they are compiled with a special flag. EMET allows applications compiled without that flag to also be opted. For more information on what DEP is and how it works, take a look at Part 1 and Part 2 of our two-part SRD blog post on it.

This protects against currently the most common technique for exploiting stack overflows in Windows. This mitigation has shipped with Windows since Windows Vista SP1. Recently with Windows 7, the ability to turn it on and off per process was added. With EMET, we provide the Windows 7 capabilities on any platform back though Windows XP. For more information, take a look at the SEHOP Overview and Window 7 SEHOP Changes blog posts.

When an exploit runs, it often cannot be sure of the address where its shellcode resides and must make a case when taking control of the instruction pointer. To increase the odds of success, most exploits now use heapspray techniques to place copies of their shellcode at as many memory locations as possible. This mitigation blocks the use of addresses most common in today’s exploits.

This is similar technology to the heap spray allocation, but designed to prevent potential null dereference issues in usermode. Currently there are no known ways to exploit them and thus this is a defense in depth mitigation technology.

This mitigation is designed to break nearly all shell code in use today. Before a piece of shellcode can do anything useful, it generally has to locate windows APIs first. This mitigation blocks a common current technique shellcode uses to do this.

ASLR randomizes the addresses where modules are loaded to help prevent an attacker from leveraging data at predictable locations. The problem with this is that all modules have to use a compile time flag to opt into this. With EMET, we force modules to be loaded at randomized addresses for a target process regardless of the flags it was compiled with.

Please stay tuned for the actual binaries which will get released in the upcoming weeks. Our blog will be updated with the latest news and download links as soon as that happens.

 We’ve put together a Bluehat video to walk through the tool and explain many of its advantages and capabilities. The video can be found on the BlueHat site linked here. We hope you enjoy it.

Thanks to Matt Miller and Ken Johnson for their work on EMET.

- Andrew Roths and Fermin J. Serna, MSRC Engineering

Background on Help and Support Center Vulnerabilities

Help and Support Center vulnerabilities, CVE-2010-1885 included, generally involve local content enabling injection of script into the Help and Support Center environment.  In the case of CVE-2010-1885, the local content targeted was a file, “sysinfomain.htm.”  This content references a helper library, “commonFunc.js,” which contains DOM-based XSS.  Specifically, commonFunc.js enables an untrusted querystring parameter to be injected onto the page.  This in turn enables the execution of attacker-controlled commands.

By design, Help and Support Center allows trusted Help content on Windows XP and Windows Server 2003 to execute privileged commands enabling Help related functionality.  Given the presence of an injection issue, the powerful Help and Support Center environment can enable execution of arbitrary code.

A Note about Potential Mitigations

The attack scenario for this vulnerability involves navigation to an hcp:// protocol URL.  Browsers including Internet Explorer 8 have recently begun to implement warning prompts before navigation to less-common URL schemes.

One example proof-of-concept exploit for CVE-2010-1885 demonstrated the use of Windows Media Player 9 to navigate to the hcp:// protocol and avoid the IE8 prompt.  More recent versions of Windows Media Player prompt before loading arbitrary HTML content and thus do not enable this attack scenario.

Nevertheless, we view the newly introduced protocol prompting behavior in browsers to be at best defense-in-depth.  We do not believe that these prompts provide sufficient mitigation for the identified Help and Support Center vulnerability in all cases.  Thus they are not called out as mitigations in MS10-042.

Ruling out URL Decoding as the Primary Issue

Our analysis of the vulnerability is that it is due to a bug in the URL validation performed by Help Center, not due to a bug in URL decoding functionality within Help and Support Center. 

As identified in the original vulnerability report, a malformed URL can result in failure of the Help and Support Center URL decoding routine.  That in itself is expected, however Help and Support Center subsequently ignores the associated failure condition and thus the resulting decoded URL is left in an arguably invalid state.  The report also made the assertion that the URL decoding could be held responsible for the security of the URL validation in Help and Support Center as a whole.  However, it is possible to construct a validly-encoded URL that would decode to the same in-memory representation as the invalidly-decoded proof-of-concept URL.  So, fixing the handling of URL decoding failure would not address the underlying vulnerability.

Digging Deeper

In the scenario identified as part of the vulnerability report, Help and Support Center validates URLs using a Jet database containing an index of locally installed Help content.  This database is located in %windir%PCHealthDatabaseHCdata.EDB.  A query is issued against the database looking for a particular piece of help content.  If this content is indexed in the database, the local file is then authorized to load within Help and Support Center.  In the case of the reported vulnerability, it was possible for an attacker to bypass validation and trigger navigation to sysinfomain.htm with a maliciously constructed URL.

CVE-2010-1885 leverages the fact that the query against the Jet database is not a true string comparison.  In reality, it’s a comparison of keys generated by the LCMapString API.  So the attacker-supplied input maps down to a string that improperly matches content contained within the Jet database.  When the query is issued against the database, the database code identifies the malformed file name to exist (several times!) even though it is not present.

Minimal Risk on Windows Server 2003

As it turns out, the HCdata.EDB database file is significantly different between Windows XP and Windows Server 2003.  On Windows Server 2003 the database file does not contain the base URLs necessary to match database queries for HCP:// protocol content.  Because the vulnerable Help and Support Center code exists on Windows Server 2003, we were able swap in the EDB file from Windows XP and observe the exploit function.  However, we were unable to construct an attack that would work with the standard Windows Server 2003 EDB file.  Nevertheless, we are addressing the issue as a low severity vulnerability on Windows Server 2003.

- MSRC Engineering Team Bloggers