Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
We are pleased to announce the release of a new version of our Enhanced Mitigation Experience Toolkit (EMET) - EMET 3.0. EMET it is a free utility that helps prevent vulnerabilities in software from being successfully exploited for code execution. It does so by opt-ing in software to the latest security mitigation technologies. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an update has not yet been applied. Download it here: http://www.microsoft.com/en-us/download/details.aspx?id=29851
This new version of the tool being released today addresses top feedback themes we have heard from users: EMET needs more enterprise configuration, deployment and reporting options. We have seen growing interest in adoption from enterprise and large scale networks and this new version includes enhancements for that segment. Here are some of the highlights of and new features in EMET 3.0.
EMET 3.0 comes with three default "Protection Profiles". Protection Profiles are XML files that contain pre-configured EMET settings for common Microsoft and third-party applications. Under EMET’s installation directory, these files are in the
folder. You can enable them as-is, modify them, or create new protection profiles based on them.
The three profiles that ship with EMET 3.0 are:
Looking inside a profile, we see a list of programs with EMET mitigations. The example below shows all EMET mitigations enabled for Windows Media Player, with the exception of Mandatory ASLR:
<Product Name="Windows Media player"> <Version Path="*\Windows Media Player\wmplayer.exe"> <Mitigation Enabled="false" Name="MandatoryASLR"/> </Version> </Product>
Notice the “*” in the Path attribute above? In EMET 3.0, we also expanded the EMET grammar rules. Existing rules that you might have continue to work as-is and it is possible now to also use wildcards in EMET rules. This means that you no longer have to use the full path of an application in EMET rules. You can use the “*” character or simply use the image name, such as “iexplore.exe” in your rules. EMET will protect them regardless of where these applications may be installed. This has been one of the most requested features.
EMET also comes with built-in support for enterprise deployment and configuration technologies. This enables administrators to use Group Policy or System Center Configuration Manager to deploy, configure and monitor EMET installations across the enterprise environment.
For Group Policy: EMET includes an ADMX file that contains the three protection profiles mentioned above as policies that can be enabled/disabled through group policy. There is also a policy that demonstrates how to add custom EMET settings.
For System Center Configuration Manager: The SCCM team blog post this morning provides a package and instructions for integration with various SCCM features. Read that blog post here: http://blogs.technet.com/b/configmgrteam/archive/2012/05/15/deploying-and-configuring-the-enhanced-mitigation-experience-toolkit.aspx
With EMET 3.0, we have included an additional new reporting capability that we call "EMET Notifier". When you install EMET 3.0, this lightweight component is set to automatically start with Windows. It will show up in the notification area of your taskbar with an EMET 3.0 icon.
EMET Notifier has two duties:
EMET events are logged via the event source called EMET. These logs can be found in the Application log. There are three levels: Information, Warning and Error. Information messages are used for logging usual operation such as the EMET Notifier starting. Warning messages are used when EMET settings change. Error messages are used for logging cases where EMET stopped an application with one of its mitigations, which means an active attack has been blocked. An example entry can be seen below.
In addition to the error messages written to the Windows Event Log, when an EMET mitigation stops (crashes) an application by blocking an exploit, a message is displayed for the user. A toast style taskbar notification states which application is being stopped and which mitigation is causing EMET to stop it. You can see an example below.
Other EMET v3 developments
In addition to these features, EMET 3.0 comes with a number of other improvements and bug fixes. More details and a FAQ can be found in the User Guide that comes with the install. However, we would like to specifically highlight a couple of things here.
First, we have tested EMET 3.0 on the Windows 8 Consumer Preview and it works great - we encountered no problems at all so we encourage you to use EMET on all versions of Windows. Second, EMET 3.0 can be installed just fine on a system where EMET 2.1 (the previous release) was already installed. An upgrade or a new installation is no different. Your existing rules built for EMET 2.1 will continue to work just fine with EMET 3.0. Third, we would like to point out that EMET is an officially-supported Microsoft tool. That is a question we get a lot from enterprise customers. Microsoft's Customer Service & Support team offers forums-based support via http://social.technet.microsoft.com/Forums/en/emet/threads. We in MSRC Engineering are also very eager to promote EMET and help you use it so we are quick to respond to feedback, ideas, suggestions, or questions via switech -at- microsoft -dot- com. Please do not hesitate to reach out to us.
I would like to thank Chengyun Chu, Elias Bachaalany, Elia Florio, Jinwook Shin, Neil Sikka, and Nitin Kumar Goel for their various contributions to this release. Also a big thank you to Jason Githens and Hema Rajalakshmi from the System Center Configuration Manager team for their help and support.
- Suha Can, MSRC Engineering
There are several interesting “stories” to tell about security update MS12-034:
Addressing the Duqu vulnerability again?
Five months ago, we released security update MS11-087 to address CVE-2011-3402, a vulnerability that was being exploited by the Duqu malware to execute arbitrary code when a user opened a malicious Office document. As you can read from the SRD blog post we published at the time, this vulnerability was due to an insufficient bounds check within the font parsing subsystem of win32k.sys.
In the time since we shipped MS11-087, we discovered that several Microsoft products contained a copy of win32k.sys’s font parsing code. Unfortunately, each copy of the code also contained the vulnerability addressed by MS11-087. The most troublesome copy was in gdiplus.dll. We know that several third party applications – 3rd party browsers in particular – might use gdiplus.dll to parse and render custom fonts. Microsoft Office’s version of gdiplus, called ogl.dll, also contained a copy of the vulnerable code. Silverlight included a copy of the vulnerable code. And the Windows Journal viewer included a copy of the vulnerable code.
The Office document attack vector leveraged by the Duqu malware was addressed by MS11-087 – Duqu is no longer able to exploit that vulnerability after applying the security update. However, we wanted to be sure to address the vulnerable code wherever it appeared across the Microsoft code base. To that end, we have been working with Microsoft Research to develop a “Cloned Code Detection” system that we can run for every MSRC case to find any instance of the vulnerable code in any shipping product. This system is the one that found several of the copies of CVE-2011-3402 that we are now addressing with MS12-034.
Why so many affected products?
At first glance, MS12-034 may seem to be addressing a number of unrelated vulnerabilities in unrelated products. For example, why would a keyboard layout handling vulnerability be addressed in the same update as a Silverlight issue? However, as described above, we needed to address the font parsing vulnerability (CVE-2011-3402) in a number of different products. As each new product was added to the security update package, the vulnerabilities planned-to-be-addressed in the same binary were also included.
Addressing CVE-2011-3402 required us to service ogl.dll, gdiplus.dll, win32k.sys, Silverlight, .NET Framework, etc. Because gdiplus.dll was being addressed, several other fixes that were scheduled to be released in the same binary were looped in to this update. For example, the local elevation of privilege vulnerabilities in win32k.sys (CVE-2012-0180,0181,1848) were added because we had already included win32k.sys to address TTF parsing issues. The Silverlight and .NET Framework vulnerabilities were added because we were already servicing those binaries via CVE-2011-3402. In the end, its probably for the best to require fewer updates to be installed but we understand that it can be confusing. Hopefully that explanation will help you understand the reasoning behind the decision to include ten CVE's in a single bulletin.
Keyboard layout behavior introduced with Windows Vista conditionally applied down-level
In addition to addressing the vulnerabilities described in the bulletin, this security update also closes the malicious keyboard layout file attack vector. Windows Vista introduced a requirement that all keyboard layout files be loaded from %windir%\system32. MS12-034 ports that change downlevel to Windows XP and Windows Server 2003 as well. With this new update in effect, vulnerabilities like CVE-2012-0181 (being addressed today) and CVE-2010-2743 (one of the privilege escalation vulnerabilities used by Stuxnet) will be non-issues. Requiring an attacker to place a malicious file in the system32 directory prevents the vulnerability from being a threat.
You can read more about how this change is rolled out in the bulletin’s FAQ section, specifically “Are there special requirements related to applying the security update packages that address CVE-2012-0181?” The change will not affect systems where a keyboard layout outside %windir%\system32 is already registered on the system. You can also read more in Microsoft KB 2686509.
Many engineers worked hard to bring this larger-than-usual MS12-034 security update to you. From the MSRC Engineering team, I especially want to thank Richard van Eeden and Cristian Craioveanu for their work on the font issues. Ali Pezeshk and Gavin Thomas both also made larger-than-usual contributions to this update. Elias Bachaalany, Elia Florio, Jinwook Shin, Neil Sikka, Ali Rahbar, and Suha Can all contributed to this update from the MSRC Engineering team. Finally, thanks to Chengyun Chu for his work on the cloned code detection system that discovered the other instances of CVE-2011-3402.
MS12-034 addresses ten CVE’s affecting a number of different products. We hope that this blog post answers questions you might otherwise have had around the servicing decisions that went into this update. If you have any further questions, please email us at switech –at- microsoft –dot- com.
- Jonathan Ness, MSRC Engineering