Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Three weeks ago, we released a beta version of EMET 4.0 to get feedback on the new EMET features and to get more real-world testing before the official release. We have been amazed and so grateful for the thousands of downloads and hundreds of emails with feature suggestions, bug reports, questions about the new features, and kind words cheering us on. Thank you (!!) to those of you who are helping us make EMET 4.0 a great release. Seeing how much the community of defenders cares about this product drives and motivates us to make it awesome! With this blog post, we want to give you an update on the EMET schedule and walk through the steps to leverage EMET 4.0’s new Certificate Trust feature.
Official release delayed two weeks to May 28, 2013
We have acted on and addressed a number of bug reports and points of feedback already. One of the most important was a vulnerability first reported by TK of NSFocus where having EMET loaded made exploitation of system vulnerabilities easier – that is fixed. We also received the “Agent not running” bug report several times and that is addressed for the final release of EMET 4.0. We are fixing several application compatibility issues reported that we otherwise would be unlikely to have discovered on our own pre-release. Your feedback is making EMET 4.0 a better product – thank you!
We want to make product changes to address more of the feedback before we release EMET 4.0 to the world. So we decided to postpone the release of final version of EMET 4.0 by two weeks, to May 28th, 2013. We are sorry if this decision may interfere with your future plans of deploying EMET, but we prefer to take some extra time to work on all the feedback received and to release a product as reliable and safe as possible.
EMET and certificate pinning
As you may know EMET 4.0 implements a new protection feature known also as “certificate pinning” which in its simplest form could be described as a method of associating an X509 certificate (and its public key) to a specific Certification Authority (root or leaf).
Certificate pinning and certificate cross-validation became two very popular topic in recent years because of the major incidents and fault happened in the PKI space; in fact the current PKI and Certification Authorities model has demonstrated some limits and shown critical issues when scaled to a globalized and fully interconnected world where it’s not entirely safe to assume that every CA in the world is immune from breach, errors or poor practices as clearly showed by the table below which summarizes the most significant PKI issues seen so far. On the other hand the reason why users should care about certificate pinning is the fact that the numbers of CA across the world and located in multiple countries has grown significantly in recent years and the entire PKI model works with the assumption that all these CA will always operate with the same level of trust and confidence.
For this reason EMET 4.0 decided to take a little step far from the traditional exploit mitigation area and introduces a new feature called Certificate Trust to allow anyone to create pinning rules for any SSL/TLS website certificate, giving the ability to detect Man-In-The-Middle attacks leveraging untrusted certificates. EMET 4.0 comes with Certificate Trust enabled by default, including a set of pre-configured websites for the most common domains used by Microsoft online services; nevertheless, since we believe that certificate pinning is a useful tool to detect MITM attacks targeting any domain and not just Microsoft services, we designed Certificate Trust totally configurable, in order to allow any user to configure custom pinning rules that will be enforced when browsing the web with Internet Explorer.
Since we received a lot of feedback about this new feature and a lot of users sent inquiries on how to properly use it, we are publishing this blog to explain how to configure and test Certificate Trust.
Introducing the Certificate Trust feature
EMET 4.0 has a main switch button in the system mitigation panel that can be used to activate or de-activate Certificate Trust. Once enabled, users have to specify which certificates and Root Certificate Authorities to trust. Users can verify that the Certificate Trust feature is activated from the EMET GUI by checking that the system status of this mitigation is “Enabled” and that Internet Explorer process (iexplore.exe) is in the list of configured apps (with or without memory mitigations enabled). This configuration allows EMET to inject into the protected process a new small module (EMET_CE.DLL) that will operate only within Internet Explorer to enforce the certificate pinning protection.
EMET pinning model is based on two simple types of metadata: Pinning Rules and Protected Websites. Users can define custom “pin” relationships between subject name(s) seen in SSL certificates and a set of trusted Root Certification Authorities. EMET supports the creation of “one-to-one” pinning rules (one domain pinned to one specific RootCA) or “one-to-many” (one domain pinned to a set of specific RootCAs), and gives the ability to define minor exceptions for each rule.
For example, let’s consider the domain “login.live.com”, which is configured and protected by default by EMET 4.0 Beta. EMET has a specific pin rule for the subject name of “login.live.com” which is linked to two RootCAs. One of these RootCAs is VeriSign RootCA, which is visible when manually inspecting the certificate for that domain. Any certificate seen by Internet Explorer for “login.live.com” and originated from a RootCA different than the two configured in EMET will be detected and reported as suspicious.
Configuring Certificate Trust: an example
In order to understand the exact steps required to create a custom pinning rule, we are providing a step-by-step configuration guide for Twitter. This guide can be used as reference to configure any other online service (e.g. webmail, social networks, file sharing, online banking, etc.) or any corporate portal that uses SSL/TLS connections (e.g. webmail.mycompany.com, fileshare.mycompany.com, etc.), and take advantage of EMET’s Certificate Trust feature.
The Certificate Trust configuration can be exported as XML file and later imported on a different machine or distributed to a corporate environment to be imported using the EMET_conf command line utility. For the Twitter example used in this blog, the exported XML configuration file is shown below:
<Issuer>CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US</Issuer>
<Expiration>5/10/2014 4:00:00 PM</Expiration>
Notes about Certificate Trust configuration
After evaluating the initial feedback received and some questions from users regarding the Certificate Trust feature, we think it’s also important to share some additional notes and guidelines for users dealing for the first time with certificates and pinning rules:
We hope you are as excited about using the final release of EMET 4.0 as we are about releasing it. If you have any questions about EMET 4.0, specifically about the Certificate Trust feature detailed in this blog post, please email us at firstname.lastname@example.org. And if you haven’t yet tested EMET 4.0 beta, download it here and try it out!
- Elia Florio, MSRC Engineering
Today, we are making available a “Microsoft Fix it” solution to block attacks leveraging the Internet Explorer 8 (IE8) vulnerability described in Security Advisory 2847140. This code-signed, easily downloadable and install-able Fix it package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time IE is loaded. Here are the links to both apply and uninstall the Fix it solution:
In this blog post, we’d like to describe the following:
Comprehensive update in testing now
We have built a comprehensive security update that addresses this vulnerability and it is currently being tested around-the-clock. We will release it as soon as testing confirms it is ready for broad release to all customers. Tomorrow, please visit our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle.
As listed in Security Advisory 2847140 and confirmed externally, Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) is a good workaround option for the in-the-wild attacks and public pentest framework that we have seen. The exploit version in the pentest framework that target Windows Vista and Windows 7 leverages a DLL module installed by Java 6 to bypass ASLR. EMET’s Mandatory ASLR feature blocks this exploit by enforcing ASLR randomization for this DLL when it gets loaded by IE8. At the moment, we are aware of a limited number of attacks in the wild and they target IE8 on Windows XP only. These exploits currently used by attackers are also blocked both by EMET’s EAF mitigation and by the EMET 3.5 TP and 4.0 Beta anti-ROP mitigations. The first ROP stage triggers EMET’s StackPointer, CallerCheck and SimExecFlow checks. Enterprises already using EMET can anlyze their machine logs to investigate possible exploitation events for this exploit reported by EMET mitigations.
For a stronger level of protection, we recommend installing the Fix it solution until the comprehensive security update is available. The Fix it applies changes to the mshtml loaded binary, similar to the changes applied by the IE team’s comprehensive security update. More information about the vulnerability, and how it is blocked by the Fix it, can be found in the next section.
How the Fix it “fixes” the vulnerable code
The vulnerability is exposed due to a page layout issue, triggered when Internet Explorer 8 is trying to calculate layout information for nodes no longer in the DOM tree. The issue is caused by layout structures that are not properly cleaned up and contain dangling pointers to page elements. When the layout is updated, the browser crashes due to accessing the freed memory. The code that cleans up the dead links already exists, but it runs after the layout structures are accessed. The solution is to move the cleanup logic before the layout structure access.
The appcompat shim-based “Fix it” protection tool does the exact same thing as the fix provided by the Internet Explorer team. This is still a workaround, but more surgical as compared to other workarounds because it blocks the root cause of the vulnerability. The shim modifies in memory the mshtml!CBlockContainerBlock::BuildBlockContainer function in order to force the code flow change that results in the layout structures being properly cleaned up before access:
InjectLoopHere: CODE XREF: CBlockContainerBlock::BuildBlockContainer+103
match:74CC08DC 8B 45 08 mov eax, [ebp+arg_0] Inject code here!!
match:74CC08DF 8B 40 08 mov eax, [eax+8]
patch:74CC08DC E9 ?? ?? ?? ?? jmp WhilepNextExistingBlock2
patch:74CC08E1 90 nop
.text:74CC08E2 C1 E8 0A shr eax, 0Ah
.text:74CC08E5 A8 01 test al, 1
.text:74CC08E7 0F 85 FB 8E FD FF jnz loc_74C997E8
WhilepNextExistingBlock: CODE XREF: CBlockContainerBlock::BuildBlockContainer-6C6CE
.text:74CC094E 39 7D F4 cmp [ebp+pNextExistingBlock], edi
.text:74CC0951 0F 85 38 36 F9 FF jnz LoopToRelocate
LoopToRelocate: CODE XREF: CBlockContainerBlock::BuildBlockContainer+2DF
.text:74C53F8F FF 75 F4 push [ebp+pNextExistingBlock]
.text:74C53F92 8B 4D 0C mov ecx, [ebp+arg_4]
.text:74C53F95 FF 75 08 push [ebp+arg_0]
.text:74C53F98 8D 55 F4 lea edx, [ebp+pNextExistingBlock]
.text:74C53F9B E8 2B 64 0A 00 call CLayoutBlock::RemoveChild ; layout structure cleanup
.text:74C53FA0 8B F0 mov esi, eax
.text:74C53FA2 3B F7 cmp esi, edi
match:74C53FA4 0F 8D A4 C9 06 00 jge WhilepNextExistingBlock
patch:74C53FA4 E9 ?? ?? ?? ?? jmp CLOBBER_NOPS_PATCH_BYTES
patch:74C53FA9 90 nop
.text:74C53FAA E9 25 58 04 00 jmp CHK_FAIL
.text:74C53FAA END OF FUNCTION CHUNK CBlockContainerBlock::BuildBlockContainer
patch:???????? 7D 07 jge WhilepNextExistingBlock3
patch:???????? E9 ?? ?? ?? ?? jmp CHK_FAIL
patch:???????? 33 FF xor edi, edi
patch:???????? 39 7D F4 cmp [ebp+pNextExistingBlock], edi
patch:???????? 0F 85 ?? ?? ?? ?? jnz LoopToRelocate
patch:???????? 8B 45 08 mov eax, [ebp+arg_0]
patch:???????? 8B 40 08 mov eax, [eax+8]
patch:???????? E9 ?? ?? ?? ?? jmp ResumeExecution
The “Fix it” solution will apply only for the x86 versions of Internet Explorer 8 that have applied MS13-028: Cumulative Security Update for Internet Explorer: April 9, 2013. Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, after you apply the yet-to-be-released final security update, you should uninstall the Fix it workaround as it will no longer be needed.
We want to reiterate that only IE8 is vulnerable to this issue and we currently see only limited attacks. We are hard at work developing a comprehensive security update. Tomorrow, please review our monthly Advance Notification Service (ANS) blog for details on the Security Updates being released in May’s Security Bulletin cycle. In the meantime, feel free to reach out to us with any questions on the above. You can contact us at email@example.com or firstname.lastname@example.org.
Special thanks to Elia Florio for his work analyzing exploits for this vulnerability.
- Cristian Craioveanu and Jonathan Ness, MSRC Engineering
Today we released ten security bulletins addressing 33 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and eight have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
(Internet Explorer 8)
Vulnerable code is also present in IE9 but not vulnerable in same way. Update for IE9 is included as defense-in-depth measure.
(Kernel mode drivers, win32k.sys and dxgkrnl.sys)
- Jonathan Ness, MSRC Engineering
MS13-037 addresses a number of vulnerabilities in Internet Explorer, several of which were reported to us by the TippingPoint Zero Day Initiative (ZDI) program. We’ve gotten questions from customers about the specific vulnerabilities purchased by ZDI from the CanSecWest pwn2own contest. We’d like to use this blog post to provide more background on the set of vulnerabilities required for an attacker to exploit modern-day browsers and the state of fixes for those specific vulnerabilities.
Exploiting recent versions of Internet Explorer
Several years ago, a single memory corruption style vulnerability in the browser could be directly leveraged to compromise a system, could be used to run code in the context of the browsing user. Microsoft has invested heavily in platform-level mitigations for client-side applications such as browsers to the extent that today multiple different vulnerabilities must now be discovered and chained together in an exploit to compromise a system. A single memory corruption style vulnerability is just the start of an attacker’s discovery process. Typically, the attacker would need to also need to bypass ASLR and discover a way out of the IE Protected Mode limited code execution environment.
ZDI reported five separate vulnerabilities to Microsoft as a result of the contest:
Status of security updates
MS13-037 addresses the two Internet Explorer vulnerabilities used in the VUPEN exploit. The Windows vulnerabilities and the IE9 broker issue will be addressed in a future security update cycle. Here’s a chart that describes the state of fixes and level of exposure for these vulnerabilities provided to us by the ZDI.
As you can see, MS13-037 addresses the primary or initial code execution vulnerabilities but we still are working on the updates to address other vulnerabilities used as part of the exploit chains to win pwn2own. Thankfully, ZDI reported those vulnerabilities directly to us and we don’t have any reason to believe that ZDI or the researchers who discovered these vulnerabilities have disclosed the vulnerability details to any third party. So we typically treat the pwn2own vulnerabilities as any other vulnerability report received as part of the coordinated vulnerability discovery process. It’s super interesting for us as security researchers ourselves to see the ingenuity displayed during the contest to exploit the hardest targets out there (!!) but its the severity of the vulnerabilities (not necessarily their debut as part of the contest) that guides our prioritization of fixes.
Each bulletin lists our “official” acknowledgement and thanks to the researchers and third parties involved in discovering and reporting these vulnerabilities to Microsoft. But today from everyone on the SRD team, we want to also pass along our thanks and a hat tip to the pwners out there – really impressive job on these vulns, guys. Thanks for helping us make the platform stronger.
- Jonathan Ness, MSRC Engineering and William Peteroy, MSRC
On May 8th, we announced that EMET 4 would have been released today, May 28th. Since that day, we had additional feedback and we are working on a few things that are requiring a little bit more time than expected.
This considered, we are not releasing EMET 4 today, and we will take a few more days to have everything prepared for the final release. We are sure that you will not be disappointed by the additions we are working on before the final release.
Also, at this point we don’t want to give a new release date yet, but expect to see EMET 4 in the next few days.
- The EMET Team.
There is much to say about the use of Java in both consumer and enterprise environments. Like any other platforms, it has both devoted supporters and fervent critics. But for most, Java is a requirement, a means to an end.
In the past few years, Java as a platform has been the target of numerous malware attacks, which exploit a number of Java runtime vulnerabilities on the target machines. The rise in Java exploitation has been attributed largely to unpatched software, although 0-day issues do creep in occasionally.
Fortunately, there are steps that can be taken to mitigate some of these issues. Oracle is providing a series of measures to prevent unauthorized Java Applets and Web Start Applications from running by requiring them to be signed with a trusted certificate. This is a great start. However, not everybody runs an up-to-date version of Java runtime. For a long time, Java updates used to install side-by-side with older versions. That’s no longer the case, but the problem of unpatched software persists. In addition, there are legacy apps that require an older platform to run.
What can be done about this? If you need to run Java inside a browser, not much -- keep your software up to date and visit only trusted websites. If you only care about running Java desktop apps, there are a few mitigation steps that allow the customer to disable Java support inside your browser, leaving desktop functionality intact. These steps will remove a prevalent remote exploit vector, but at the same time keep Java installed for local applications. This subject has been covered elsewhere; for instance, here.
Our customers tell us that the most effective mitigation tactics are both complete (covering all software versions, past and current) and friendly to enterprises, which face complex deployment issues. In order to address these concerns, we have issued an update to KB2751647 – How to disable Java web plugin in Internet Explorer. We are making available a “Microsoft Fix it” solution to block all Java web-attack vectors through Internet Explorer. The solution will work for all versions of Java (tested 5 and above) and all supported versions of Internet Explorer (32-bit or 64-bit):
Apply Fix it
Uninstall Fix it
Microsoft Fix it 50994
Microsoft Fix it 50995
The Fix it solution consists of two parts. The first makes use of Windows Application Compatibility Toolkit, changing the behavior of Internet Explorer at runtime so that it will prevent the load of Oracle’s Java Web plugins. This is achieved by hooking all LoadLibrary* functions so that they return NULL (last error ERROR_FILE_NOT_FOUND) when attempting to load all Java ActiveX dlls (npjpi*.dll, jp2iexp.dll). The second part prevents Internet Explorer from automatically opening JNLP files. It does this by clearing the ACL (access control list) of the JNLP protocol handler registry location (HKCR\JNLPFile), thus preventing all user apps from reading its contents.
This solution covers current and past versions of Java, as well as foreseeable future versions. It does not interfere with Java’s update mechanism either. In fact, the Fix it works as expected even if installed prior to any installation of Java. It can also be easily deployed making use of the non-interactive options of msiexec.
A mitigation.When you cannot let go, blockJava in IE
- Cristian Craioveanu, MSRC Engineering, with help and support from Elia Florio and Gerardo Di Giacomo (thank you!)