*** UPDATE: Version 2.0 of EMET is now available. Click here to read more about it. ***
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 3rd 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:
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 3rd 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
Today we released the fix for CVE-2010-0266, an Important severity vulnerability in Microsoft Office Outlook. Yorick Koster working with the SSD/SecuriTeam Secure Disclosure program reported this issue.
What’s the risk?
This vulnerability enables an attacker to spoof a dangerous e-mail attachment to appear legitimate / benign. If a victim user were to open the attachment, code from a remote UNC path could execute without prior warning.
UNC paths are commonly known to reference SMB resources. However, edge firewalls typically block SMB, so SMB is less likely to be used for Internet-based attacks. That said, UNC paths can also access resources via HTTP. On Windows XP and more recent platforms, the WebDAV mini-redirector (a.k.a. the WebClient service) enables web content to be accessed via UNC paths. This is more likely to pass through firewalls as WebDAV is an extension of HTTP and commonly traverses port 80 like web browser traffic.
To see the WebDAV mini-redirector in action, try the following:
How can I protect myself?
First, we recommend applying the update as soon as possible. If you are not able to apply the update there is a workaround that can help protect your environment from WebDAV-based attacks. While this won’t prevent all attacks it will block the most likely vector for Internet-based attacks.
Workaround - Disable the WebClient Service
Disabling the WebClient service helps protect affected systems from attempts to exploit this vulnerability by blocking the most likely remote attack vector through the Web Distributed Authoring and Versioning (WebDAV) client service. After applying this workaround it will still be possible for remote attackers who successfully exploit this vulnerability to cause Microsoft Office Outlook to run programs located on the targeted user's computer or the Local Area Network (LAN), but users will be prompted for confirmation before opening arbitrary programs from the Internet.
To disable the WebClient Service, follow these steps:
Impact of workaround
When the Web Client service is disabled, Web Distributed Authoring and Versioning (WebDAV) requests are not transmitted. If the Web Client service is disabled, any services that explicitly depend on the Web Client service will not start, and an error message will be logged in the System log. For example, WebDAV shares will be inaccessible from the client computer.
How to undo the workaround.
To enable the WebClient Service, follow these steps:
Thanks to Kevin Brown, Naveen Palavalli, and Andrew Roths for contributing to this blog post.
- David Ross, MSRC Engineering
Today we released MS10-042 to address CVE-2010-1885, a Critical severity security issue in the Help and Support Center. Windows XP is affected and we have seen limited attacks, so we encourage everyone to depoy the update right away. Windows Server 2003 also contains the vulnerable code; however, we have not identified a way for an attacker to exploit it. Uplevel versions of Windows do not contain Help and Support Center and as such are not vulnerable.
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.
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%\PCHealth\Database\HCdata.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