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.
Configuration
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
Deployment\Protection Profiles
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.
Deployment
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
Reporting
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.
Acknowledgements
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.
Conclusion
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
Today we released 6 security bulletins. Four have a maximum severity rating of Critical with the other two addressing Important class vulnerabilities. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
(Windows Common Controls)
(Internet Explorer)
(Authenticode)
(.NET Framework)
(Office Works Converter)
(Forefront Unified Access Gateway [UAG])
Security Update MS12-027 addresses a code execution vulnerability in MSCOMCTL.OCX, the Windows Common Controls ActiveX control. By default, this component is included with all 32-bit versions of Microsoft Office. We’d like to cover the following topics in this blog post:
Limited, targeted attacks leveraging this vulnerability
We list MS12-027 as our highest priority security update to deploy this month because we are aware of very limited, targeted attacks taking advantage of CVE-2012-0158 vulnerability using specially crafted Office documents as exploit vector. The specific samples that we have seen have been RTF files attempting to exploit the vulnerability when opened in either WordPad or Microsoft Word. People who install the MS012-027 patch are protected against CVE-2012-0158 so we recommend applying the update right away. Microsoft Word includes various on-by-default mitigations and optional security hardening features that you might consider enabling. Read on to find out more.
Microsoft Word 2010 Protected View as a mitigation
By default, Microsoft Office 2010 opens documents originating from the Internet and from other potentially unsafe locations in a mode called Protected View. This mode does not allow ActiveX controls to load. If a victim running Office 2010 were to receive an exploit for CVE-2012-0158 over the internet or via email, the victim would need to click the Protected View's "Enable Editing" button before the malicious code would be allowed to run. The screenshots below show two examples of Protected View.
and
Disabling ActiveX controls in Microsoft Office
ActiveX-based attacks with documents are not new. In this blog we have covered the Behavior of embedded ActiveX controls in Microsoft Office documents (http://blogs.technet.com/b/srd/archive/2009/03/03/behavior-of-activex-controls-embedded-in-office-documents.aspx) three years ago, giving good advice and best practices on how to restrict (or disable) the initialization of embedded controls.
Without going into the details of the previous blog, we’ll just mention once more that Office 2007 and 2010 editions have a dedicated panel for ActiveX controls in Trust Center Settings which allows, in its safest configuration, to completely disable all controls embedded in documents or to prompt a warning dialog when a document tries to use certain type of controls as showed by the following picture.
Disabling specific embedded ActiveX controls with Office kill bit
The ActiveX kill bit feature has proven an effective measure in reducing the attack surface of Internet Explorer during the past years and so Microsoft Office has introduced this feature in a similar way. Office 2007 honors the Internet Explorer kill bit list. Office 2010 takes this a step further by blocking ActiveX controls from the Internet Explorer list and also allowing users to independently control through the registry which COM objects will not be able to run (Office 2010 COM kill bit). If the kill bit is set for the same ActiveX control in both locations, Office and Internet Explorer, and there is a conflict between the two settings, the Office COM kill bit has precedence. The location for setting the Office 2010 COM kill bit in the registry is HKLM/Software/Microsoft/Office/Common/COM Compatibility/{CLSID}, where CLSID is the class identifier of the COM object. To enable the Office COM kill bit for a specific control, first you need to add a registry key with the CLSID of the ActiveX control to block (NOTE: don’t forget the { } parenthesis!) and then add a value of 0x00000400 to the Compatibility Flags REG_DWORD.
Documents containing embedded controls will still be opened by Microsoft Office (some content of the document will be available and visible), however any blocked ActiveX control will not be loaded and will show up in the Office application as showed in the following picture:
Additional details about Office 2010 kill bit can be found at the following link: “Plan security settings for ActiveX controls for Office 2010” http://technet.microsoft.com/en-us/library/cc179076.aspx
Conclusions
The first option described in this blog (Trust Center settings) provides a general and very effective measure against attacks similar to the one observed for CVE-2012-0158, however this configuration needs to be carefully evaluated before wide adoption on corporate networks because it may block the execution of Office documents and applications with embedded ActiveX controls (e.g. an Excel spreadsheet using listbox control for selection). Organizations that have a highly restrictive security environment and concerns about ActiveX controls may consider deploying this setting via group policy or registry.
On the other hand, the second option described today (Microsoft Office 2010 COM kill bit) offers to users and organizations a more selective way to control which embedded ActiveX controls can be trusted and loaded from documents. An organization seeking to block a limited set of untrusted controls without having legacy problems with existing applications may find more useful deploying selective kill-bit configurations instead of using the general “disable all” option discussed earlier.
- Elia Florio, MSRC Engineering
One of the security bulletins released today, MS12-025, addresses a code execution vulnerability in the .NET Framework. To exploit the vulnerability, an attacker would build a malicious XBAP application and lure victims to a malicious website serving the XBAP.
The good news is that a zero-click “driveby” style attack is no longer possible from the Internet on workstations where MS11-044 (published June 2011) has been installed. MS11-044 introduced an additional security prompt for all XBAP’s encountered from the Internet Zone. A redacted example is pictured below:
We recommend not allowing XBAP’s to run unless you know and trust the Publisher listed in the security dialog. The security bulletin outlines steps to disable XAML browser applications in Internet Explorer on a per-zone basis if you do not need to use this functionality.
Security Update MS12-020 addresses two vulnerabilities in Microsoft’s implementation of the Remote Desktop Protocol (RDP). One of the two, CVE-2012-0002, is a Critical, remote code execution vulnerability affecting all versions of Windows. This blog post shares additional information with the following goals:
Note that CVE-2012-0002 was privately reported and we are not aware of any attacks in the wild. Additionally, the remote desktop protocol is disabled by default. However, due to the attractiveness of this vulnerability to attackers, we anticipate that an exploit for code execution will be developed in the next 30 days.
We understand and appreciate that our customers often need time to evaluate and install bulletins as appropriate for their environment. For systems running RDP without Network-Level Authentication (NLA) enabled, this post includes information on a mitigation that may be applied in advance of the bulletin.
Pre-auth, network accessible, service running as SYSTEM
This issue is potentially reachable over the network by an attacker before authentication is required. RDP is commonly allowed through firewalls due to its utility. The service runs in kernel-mode as SYSTEM by default on nearly all platforms (except for one exception described below). During our investigation, we determined that this vulnerability is directly exploitable for code execution. Developing a working exploit will not be trivial – we would be surprised to see one developed in the next few days. However, we expect to see working exploit code developed within the next 30 days.
The good news is that the Remote Desktop Protocol is disabled by default, so a majority of workstations are unaffected by this issue. However, we highly encourage you to apply the update right away on any systems where you have enabled Remote Desktop.
Workaround option: Enable Network Level Authentication (NLA) on Windows Vista and later platforms
There is something you can do to substantially reduce the risk on Windows Vista and later systems where RDP is enabled: You can enable Remote Desktop’s Network Level Authentication (NLA) to require authentication before a remote desktop session is established to the remote desktop server. On systems with NLA enabled, the vulnerable code is still present and could potentially be exploited for code execution. However, NLA would require an attacker to first authenticate to the server before attempting to exploit the vulnerability.
You can find instructions to enable NLA interactively or via group policy at http://technet.microsoft.com/en-us/library/cc732713.aspx. We’ve prepared a one-click “Fix it” solution that takes a registry-based approach to enable NLA. It is a simple MSI package that enumerates each of the “listener” registry subkeys under HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations and sets the “UserAuthentication” REG_DWORD to 1. The links below enable and disable NLA:
Enabling NLA will prevent older clients (including Windows XP and Windows Server 2003) from connecting, by default. NLA will not disrupt remote desktop connections initiated by Windows Vista and later versions of Windows because they support NLA by default. If you need to initiate a remote desktop protocol connection to an NLA-enabled server from a Windows XP client, you can install support for Credential Security Support Provider (CredSSP) on each connecting Windows XP client. Instructions for doing so can be found here: http://support.microsoft.com/kb/951608. You can also use this one-click Fix it solution on Windows XP SP3 clients to enable support for NLA:
Platforms and scenarios at reduced risk
Just to reiterate, remote desktop is not enabled by default and is not commonly enabled on client workstations. Additionally, there are two common scenarios where remote desktop services could be enabled but on which the vulnerability poses reduced risk.
First, servers providing Terminal Services Gateway service are not directly vulnerable to this issue. The reason is that external users connect to the TS Gateway by using RDP encapsulated in RPC over HTTPS via port 443. The TS gateway computer removes the SSL encryption from the RDP traffic and then forwards the traffic to port 3389 of the destination computer on the internal network. The Terminal Services session is then established with that destination computer, not with the TS Gateway system.
The second scenario at reduced risk is Windows Server 2008 R2 SP1 servers using the Remote Desktop feature called RemoteFX. This is a common scenario in virtualized environments. This scenario is at reduced risk because the vulnerable code is running in user-mode (not kernel-mode) with NetworkService rights (not SYSTEM rights). While NetworkService privileges are less severe than executing code as SYSTEM, it would still grant attackers an unfortunate foothold in the network – so it would be a mistake to allow this reduced risk discussion to slow your rate of bulletin application.
We are actively engaged with our MAPP partners to build network-based detection and protection signatures for this issue. The nature of this particular vulnerability should allow for strong IDS and IPS protection. So an additional scenario leading to reduced risk is to have one’s systems behind a protection product from one of our MAPP partners who has built strong detection for this issue.
We urge you to promptly apply this security update. We also encourage you to consider how you might harden your environment against unauthenticated, attacker-initiated RDP connections. Please let us know if you have any questions that can help you speed your deployment. You can reach out to us at switech –at- microsoft –dot- com.
- Suha Can and Jonathan Ness, MSRC Engineering
Today we are shipping a security update to address a Critical-class memory corruption vulnerability in the Microsoft C Run-Time Library (msvcrt.dll) shipped with Windows. We have issued the bulletin with Critical severity because attackers could potentially trigger the vulnerability by luring a victim into browsing to a malicious webpage that launches Windows Media Player, or by opening a malicious file with Windows Media Player.
Seldom-used functionality
While the Windows Media Player attack vector is unfortunate, one might look at the affected DLL (msvcrt.dll), recognize that a number of Microsoft applications load the DLL, and speculate that a large percentage of applications might be vulnerable. Thankfully, that is not the case. Based on what we have seen in our code base, the affected functions are rarely used by components shipping with Windows. At this time, Media Player is the only known vector to provide an exploit path for the vulnerability. And even if other attack vectors are discovered, after applying the security update, all Microsoft products will be protected from the issue.
Applications built with recent versions of Visual Studio are safe by default
All applications built with Visual Studio 2003 and higher are not affected by this issue, unless they are specifically loading msvcrt.dll. Starting from Visual Studio 2003, any program that is dynamically linked to the C Run-Time library will use msvcrXX.dll instead of msvcrt.dll.
It is important to note that msvcrt.dll is a known DLL. This means that it is a system component owned and built by Windows. It is intended for future use only by system-level components. An application should use and redistribute msvcrXX.dll. Windows will only look in %WINDIR%\system32 to locate msvcrt.dll. Any application that is linked to msvcrt.dll will load the vulnerable version, regardless of the presence of another version in the current directory – though, again, applying this bulletin eliminates the issue.
Guidance for 3rd party application developers
If you have developed an application by statically linking to the C Run-Time library shipped with Visual Studio, you are safe. If your program is dynamically linked to the C Run-Time library, then you should ensure that all your objects are linked with a recent version of Visual Studio. This will assure that you are using msvcrtXX.dll and are not affected by this problem.
- Ali Rahbar, MSRC Engineering
Today, we shipped security update MS12-014 to address an issue in the Indeo codec. With this blog post, we hope to preemptively answer some common questions that are likely to surface as researchers analyze this security update.
Indeo: Blast from the Past
Indeo is a video codec that was first developed in 1992, long before some of you reading this blog post were born. :) In the days before MPEG – and more than a decade before youtube – Indeo was one of the first video codecs allowing full-speed video playback without using hardware acceleration.
However, today Indeo is an obsolete technology. In fact, Windows Vista and all later versions of Windows shipped with the codec disabled by default. In 2009, we took a further step of attack surface reduction for older versions of Windows by releasing a security advisory and shipping an update to block Indeo from being launched in Internet Explorer or Windows Media Player. That update, shipped via Automatic Updates, removed the most common remote attack vectors for this code while still allowing games or other legacy applications to leverage the codec locally and continue to function.
MS12-014: Why and How
Windows now blocks the remote video playback functionality of Indeo but the codec itself and its infrastructure remain on the system for legacy application support. Unfortunately, a DLL Preloading issue has been identified leveraging Indeo. In the following set of circumstance, an attacker could run arbitrary code on a system:
Due to the particular challenges in servicing Indeo, we took an unusual approach this time. This security update drops a “dummy DLL” on the system having the filename that the attacker’s malicious DLL would need to have to exploit the vulnerability. This effectively removes the vulnerability because the DLL will be found already on the system and Indeo will not attempt to load a malicious DLL from the attacker-controlled share.
Hope that helps answer questions you might have about this security update.
Thanks to Josh Carlson, MSRC Ops for the help with this one. (and congrats on shipping your first bulletin)
Today we released nine security bulletins. Four have a maximum severity rating of Critical with the other five having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
(C Runtime [msvcrt.dll])
(.NET, Silverlight)
CVE-2012-0014 does not affect any ASP.NET scenario running at Medium Trust or Lower.
(Kernel Mode Drivers)
(AFD.sys)
The other vulnerability is exploitable for local elevation of privilege on 64-bit platforms only.
(Visio Viewer)
(SharePoint)
(Indeo)
(ColorUI)
Only affects Windows Server 2008 and Windows Server 2008 R2 because the DLL was removed. However, DLL Preloading vulnerabilities like this one are less likely to be exploited on server platforms due to the extensive user interaction required.
This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.
CVE-2012-0003
The most severe of these vulnerabilities is CVE-2012-0003 which is a Critical, Remote Code Execution vulnerability. This CVE affects all editions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Windows 7 is not affected by this vulnerability.
An effective workaround for CVE-2012-0003 is to disable Directshow’s MIDI parsing. Apply the following registry file would unregister the MIDI parser in Directshow.
Windows Registry Editor Version 5.00 [-HKEY_CLASSES_ROOT\CLSID\{D51BD5A2-7548-11CF-A520-0080C77EF58A}]
CVE-2012-0004
CVE-2012-0004 is an Important-class vulnerability also involving Windows Media Player. The vulnerability in the closed caption decoding component (L21 decoder) is contained within DirectShow. Therefore, the multimedia applications that leverage DirectShow to decode closed caption streams might be affected.
As a mitigation, the latest WMP player, WMP12, has closed caption turned off by default. As shown in the below picture, the setting to display close caption content is disabled. Therefore, WMP12 users are not affected by this vulnerability by default.
Summary
MS12-004 is our top-priority bulletin for January 2012; though the mitigation described above is effective and we have seen no exploitation attempts against either of the CVEs covered, we recommend that customers apply the bulletin as soon as possible.
Special thanks to Jeremy Tinder in MSRC and Ali Rahbar in MSRC Engineering.
- Chengyun Chu, MSRC Engineering