Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Today, we are thrilled to announce a preview release of the next version of the Enhanced Mitigation Experience Toolkit, better known as EMET. You can download EMET 5.0 Technical Preview here. This Technical Preview introduces new features and enhancements that we expect to be key components of the final EMET 5.0 release. We are releasing this technical preview to gather customer feedback about the new features and enhancements. Your feedback will affect the final EMET 5.0 technical implementation. We encourage you to download this Technical Preview, try it out in a test environment, and let us know how you would like these features and enhancements to show up in the final version. If you are in San Francisco, California, for the RSA Conference USA 2014, please join us at the Microsoft booth (number 3005) for a demo of EMET 5.0 Technical Preview and give us feedback directly in person. Several members of the EMET team will be demonstrating at the Microsoft booth for the entire Conference.
As mentioned, this Technical Preview release implements new features to disrupt and block the attacks that we have detected and analyzed over the past several months. The techniques used in these attacks have inspired us with new mitigation ideas to disrupt exploitation and raise the cost to write reliable exploits. The EMET 5.0 Technical Preview also implements additional defensive mechanisms to reduce exposure from attacks.
The two new features introduced in EMET 5.0 Technical Preview are the Attack Surface Reduction (ASR) and the Export Address Table Filtering Plus (EAF+). Similar to what we have done with EMET 3.5 Technical Preview, where we introduced a new set of mitigations to counter Return Oriented Programming (ROP), we are introducing these two new mitigations and ask for your feedback on how they can be improved. Of course, they are a “work in progress.” Our goal is to have them polished for the final version of EMET 5.0.
Let’s see in detail what these two new mitigations do, and the reasoning that led us to their implementation.
In mid-2013, we published a Fix it solution to disable the Oracle Java plug-in in Internet Explorer. We received a lot of positive feedback and a number of suggestions on how we could improve the Fix it. The most recurring suggestion we received was to allow the Oracle Java plug-in on intranet websites, which commonly run Line-of-Business applications written in Java, while blocking it on Internet Zone websites. In addition to that Java-related customer feedback, we have also seen a number of exploits targeting the Adobe Flash Player plug-in. For example, the RSA breach was enabled by an Adobe Flash Player exploit embedded inside a Microsoft Excel file and a number of targeted attacks have been carried out by Adobe Flash Player exploits embedded in Microsoft Word documents, as described by Citizen Lab. We decided to design a new feature that can be used to mitigate similar situations and to help to reduce the attack surface of applications. We call this feature Attack Surface Reduction (ASR), and it can be used as a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.
The example below shows ASR in action, preventing Microsoft Word from launching an Adobe Flash Player file embedded in the document. By default, EMET 5.0 Technical Preview comes pre-configured to block certain plug-ins from being loaded by Internet Explorer, Microsoft Word and Microsoft Excel. The feature is fully configurable by changing two registry keys that list the names of the plug-ins to block, and, if supported, the security zones that allow exceptions. For more details on how to configure ASR please refer to the EMET 5.0 Technical Preview user guide.
We also added new capabilities to the existing Export Address Table Filtering (EAF). EAF+ consolidates protection of lower-level modules and prevents certain exploitation techniques used to build dynamic ROP gadgets in memory from export tables. EAF+ can be enabled through the “Mitigation Settings” ribbon. When EAF+ is enabled, it will add the following additional safeguards over-and-above the existing EAF checks:
Add protection for KERNELBASE exports in addition to the existing NTDLL.DLL and KERNEL32.DLL
Perform additional integrity checks on stack registers and stack limits when export tables are read from certain lower-level modules
Prevent memory read operations on protected export tables when they originate from suspicious modules that may reveal memory corruption bugs used as “read primitives” for memory probing
For example, the third protection mechanism in the list above mitigates the exploitation technique developed in Adobe Flash Player used in some recent Internet Explorer exploits (CVE-2013-3163 and CVE-2014-0322), where the attacker attempted to build ROP gadgets by scanning the memory and parsing DLL exports using ActionScript code. Exploits for these vulnerabilities are already blocked by other EMET mitigations. EAF+ provides another way to disrupt and defeat advanced attacks. The screenshot below shows the exploit for CVE-2014-0322 in action on Internet Explorer protected by EMET 5.0 Technical Preview with only EAF+ enabled.
This Technical Preview enables the “Deep Hooks” mitigation setting. We have been working with third-party software vendors whose products do not run properly with Deep Hooks enabled. We believe these vendors have resolved the application compatibility issues that previously existed with Deep Hooks enabled. We enable Deep Hooks in the Technical Preview to evaluate the possibility of having this setting turned on by default in the final EMET 5.0 release because it has proven to be effective against certain advanced exploits using ROP gadgets with lower level APIs. We have also introduced some additional hardening to protect EMET’s configuration when loaded in memory, and fixed several application compatibility issues including a common one that involves Adobe Reader and the “MemProt” mitigation.
We’d like to thank Spencer J. McIntyre from SecureState, Jared DeMott from Bromium Labs, along with Peleus Uhley and Ashutosh Mehra from the Adobe Security team for their collaboration on the EMET 5.0 Technical Preview.
We are excited for this Technical Preview and we hope that the additions are as valuable for our customers as they are for us. We invite you to install and give EMET 5.0 Technical Preview a try; we look forward to hearing your feedback and suggestions on how to enhance the new features that we have introduced. We would also welcome any suggestions for additional new features you’d like to see included in the final version of EMET 5.0. We greatly value the feedback we receive, and we want to build a product that not only provides additional protection to systems but is also easy to use and configure. We then invite you all to download EMET 5.0 Technical Preview and drop us a line!
The EMET Team
Today, we released Security Advisory 2934088 to provide guidance to customers concerned about a new vulnerability found in Internet Explorer versions 9 and 10. This vulnerability has been exploited in limited, targeted attacks against Internet Explorer 10 users browsing to www.vfw.org and www.gifas.asso.fr. We will cover the following topics in this blog post:
As described in Security Advisory 2934088, both Internet Explorer 9 and Internet Explorer 10 contain the vulnerable code. However, we have not seen any exploit code capable of triggering the vulnerability on Internet Explorer 9. The chart below may help explain the risk by platform:
Steps you can take to stay safe
Any of the following three protection mechanisms will protect you from exploits we have seen that leverage this vulnerability for code execution:
1 – Upgrade to Internet Explorer 11
2 – Install the Enhanced Mitigation Experience Toolkit (EMET)
3 – Install the Fix it workaround tool
Upgrading to Internet Explorer 11 is the best way to stay safe from exploit attempts targeting this vulnerability.
The Enhanced Mitigation Experience Toolkit (EMET) is also an effective way to block the targeted attacks we have analyzed. This particular exploit explicitly checks for EMET and refuses to run on any system where EMET is installed. However, even with the exploit’s EMET check removed, the default configuration of EMET blocks the attack. In this particular case, EMET’s EAF and Anti-Detour features block the exploit in the default EMET configuration. With EMET’s “Deep Hooks” feature enabled, the MemProt, StackPivot, and CallerCheck features each independently are capable of blocking this exploit. We are pleased to see EMET continuing to provide protection for a significant portion of memory corruption exploits today. On that note, we found that in the second half of 2013, all in-the-wild exploits that we encountered that have leveraging memory corruption for code execution were blocked by EMET! We recommend that all customers install this tool. Watch next week for an announcement at the RSA Conference about the future of EMET.
The third, and likely easiest way to protect yourself from attempts to exploit the vulnerability, is to install the Fix it workaround tool released in today’s advisory. You can refer to Knowledge Base Article 2934088 for complete details but simply clicking through the “Fix It” installer from the following link will protect your system from attempts to exploit the vulnerability:
Apply Fix it
Uninstall Fix it
Enable the CVE-2014-0322 Workaround
Uninstall the CVE-2014-0322 Workaround
Installing the Fix it does not require a reboot but administrative privileges on the system are required. The Fix it installation will be effective on any Internet Explorer 9 or Internet Explorer 10 system where the most recently-released security update (MS14-010) has already been installed. More specifically, the appcompat shim is enabled for the Internet Explorer process where mshtml.dll is one of the following four versions: 9.0.8112.16533, 9.0.8112.20644, 10.0.9200.16798, or 10.0.9200.20916. The eventual security update that addresses this vulnerability will ship with an incremented mshtml.dll version number, thereby automatically obsoleting this Fix it.
You can read more about previous instances of this temporary workaround technique at http://blogs.technet.com/b/srd/archive/tags/fixit/. Fix its have been a popular mitigation technique with our customers to cover the gap between the time when an exploit appears and the time when a final, comprehensive, fully-tested security update is available for wide distribution. The last instance of a Fix It tool to address an Internet Explorer vulnerability (addressed by MS13-080) was installed on 23 million computers. The most recent security-related Fix it solution mitigated an Office vulnerability that was subsequently addressed by MS13-096. That Fix It solution was installed on 57 million computers. We mention these numbers with the hope of giving you confidence that a number of your IT Pro peers are using Fix it solutions to protect their enterprise network.
More details about the vulnerability and exploit
More details about the Fix it tool
The Fix it redirects execution of two functions, mshtml!CMarkup::InsertElementInternal and mshtml!CMarkup::InsertTextInternal, to the code introduced by the appcompat shim. Similar changes are made in both functions. Let’s take a closer look at mshtml!CMarkup::InsertElementInternal:
0:020> u mshtml!Cmarkup::InsertElementInternal
e9d3d2a500 jmp MSHTML!SZ_HTMLNAMESPACE+0xf (66bb43c7) // we redirect execution
0:020> u 66bb43c7
60 pushad //save registers
8bc8 mov ecx,eax //move the this* pointer to ecx
e818468bff call MSHTML!CMarkup::CLock::CLock+0x2 (664689e7) //call into the code where we AddRef() on this CMarkup object
61 popad //restore our registers
55 push ebp //execute the code we overwrote in the jump to this shim
8bec mov ebp,esp
e91c2d5aff jmp MSHTML!CMarkup::InsertElementInternal+0x5 (661570f4) //jump back to the next instruction after the our redirection point
Similar to the Fix it solution for CVE-2013-3893, the shim leverages slack space near the end of the mshtml.dll’s .text section. Astute readers may notice that the appcompat shim does not introduce any code to reduce the reference count on the CMarkup object. Said another way, the appcompat shim introduces a memory leak. The memory is restored when an IE tab (process) is terminated. This minor side effect of the workaround tool is harmless and of course it won’t be present in the final comprehensive security update for this vulnerability.
Thanks to Richard Van Eeden, Axel Souchet, Chengyun Chu, and Elia Florio for the help triaging this vulnerability and help building the Fix it workaround tool.
Please let us know if you have any questions about the risk posed by this vulnerability, the exploits we have seen leveraging the vulnerability for code execution, or mitigation opportunities available to protect your systems. You can email us at email@example.com with [SRD] in subject line. Or if you plan to attend the RSA Conference in San Francisco, CA next week, feel free to stop by the Microsoft Booth #3005 to talk to us in person. We’re looking forward to announcing EMET news on Tuesday morning.
- Neil Sikka, MSRC Engineering (@neilsikka)
Today we released seven security bulletins addressing 31 unique CVE’s. Four bulletins have a maximum severity rating of Critical while the other three 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.
CVE-2014-0257 addresses sandbox escape vulnerability invoving com objects running code out-of-process.
CVE-2014-0295 addresses the vsab7rt.dll ASLR bypass described at http://www.greyhathacker.net/?p=585.
(Forefront Protection for Exchange)
- Jonathan Ness, MSRC
Today we released four security bulletins addressing six CVE’s. All four bulletins 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.
(NDProxy, a kernel-mode driver)
Addresses vulnerability described by security advisory 2914486.
(win32k.sys, a kernel-mode driver)
(Microsoft Dynamics AX)
- Jonathan Ness, MSRC engineering
In our previous posts in this series, we described various mitigation improvements that attempt to prevent the exploitation of specific classes of memory safety vulnerabilities such as those that involve stack corruption, heap corruption, and unsafe list management and reference count mismanagement. These mitigations are typically associated with a specific developer mistake such as writing beyond the bounds of a stack or heap buffer, failing to correctly track reference counts, and so on. As a result, these mitigations generally attempt to detect side-effects of such mistakes before an attacker can get further along in the exploitation process, e.g. before they gain control of the instruction pointer.
Another approach to mitigating exploitation is to focus on breaking techniques that can apply to many different classes of memory safety vulnerabilities. These mitigations can have a broader impact because they apply to techniques that are used further along in the process of exploiting many vulnerabilities. For example, once an attacker has gained control of the instruction pointer through an arbitrary vulnerability, they will inherently need to know the address of useful executable code to set it to. This is where well-known mitigations like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) come into play – both of which have been supported on Windows for many releases now. When combined, these mitigations have proven that they can make it very difficult to exploit many classes of memory safety vulnerabilities even when an attacker has gained control of the instruction pointer.
In recent years, attackers have been increasingly forced to adapt to exploiting vulnerabilities in applications that make use of a broad range of mitigations, including DEP and ASLR. As our previous blog post explains, there are scenarios where both DEP and ASLR can be bypassed, and it is no surprise that attackers have been increasingly focused on improving their ability to do so. Likewise, attackers have placed greater interest on finding classes of vulnerabilities, such as use after free issues, that can grant them more flexibility when attempting to develop an exploit. In light of these trends, we focused a significant amount of attention in Windows 8 and Windows 8.1 on improving the robustness of mitigations that break exploitation techniques that apply to many classes of vulnerabilities. In particular, this blog post will cover some of the noteworthy improvements that have been made to ASLR, such as eliminating predictable address space mappings, increasing the amount of entropy that exists in the address space, and making it more difficult to disclose address space information where possible.
For compatibility reasons, executable images (DLLs/EXEs) must indicate their desire to be randomized by ASLR through the /DYNAMICBASE flag provided by the Visual C++ linker. If an executable image has not been linked with /DYNAMICBASE, the Windows kernel will attempt to load the image at its preferred base address. This can cause the executable to reliably load at a predictable location in memory. While this limitation of ASLR on Windows is by design, real-world exploits for software vulnerabilities have become increasingly reliant on executable images that have not enabled support for ASLR.
To generically mitigate this issue, an application running on Windows 8 (or Windows 7 with KB 2639308 installed) can elect to enable a security feature known as Force ASLR. When enabled, this feature forces all relocatable images to be randomized when they are loaded by the application, including those images which have not been linked with /DYNAMICBASE. This is designed to prevent executable images from being loaded at a predictable location in memory. If desired, an application can also elect to prevent non-relocatable images from being loaded.
Since the Force ASLR feature will cause executable images to be randomized that have not enabled support for ASLR, there is a risk that a compatibility problem may be encountered. In addition, the method used to forcibly relocate executable images that have not been built with /DYNAMICBASE can have a performance impact due to decreased page sharing. This is because Force ASLR essentially mimics the behavior of a base address collision and thus may incur a memory cost due to copy-on-write. As such, the Force ASLR feature is not enabled by default for applications running on Windows 8. Instead, applications must explicitly enable this feature.
The Force ASLR feature has been enabled by default for critical applications such as Internet Explorer 10+, Microsoft Office 2013, and Windows Store applications. This means an attacker attempting to exploit vulnerabilities accessible through these applications will not be able to rely on non-randomized executable images. For example, our recent security update to enable ASLR for HXDS.DLL would not appreciably impact the security posture of applications that enable Force ASLR because this non-ASLR DLL would already get randomized. Going forward, attackers will most likely need to rely on a vulnerability-specific address space information disclosure when exploiting applications that completely enable ASLR or that make use of Force ASLR.
Virtual memory allocations that are made by an application can have their base address assigned in one of three ways: bottom-up, top-down, or based. The bottom-up method searches for a free region starting from the bottom of the address space (e.g. VirtualAlloc default), the top-down method searches starting from the top of the address space (e.g. VirtualAlloc with MEM_TOP_DOWN), and the based method attempts to allocate memory at a supplied base address (e.g. VirtualAlloc with an explicit base). In practice, the majority of the memory that is allocated by an application will use the bottom-up allocation method, and it is rare to see applications use the based method for allocating memory.
Prior to Windows 8, bottom-up and top-down allocations were not randomized by ASLR. This meant that allocations made through functions like VirtualAlloc and MapViewOfFile had no entropy and could therefore be placed at a predictable location in memory (barring non-deterministic application behavior). While certain memory regions had their own base randomization, such as heaps, stacks, TEBs, and PEBs, all other bottom-up and top-down allocations were not randomized.
Starting with Windows 8, the base address of all bottom-up and top-down allocations is explicitly randomized. This is accomplished by randomizing the address that bottom-up and top-down allocations start from for a given process. In this way, fragmentation within the address space is minimized while also realizing the benefits of randomizing the base address of all memory allocations that are not explicitly based.
For compatibility reasons, applications must indicate that they support bottom-up and top-down randomization. An application can do this by linking their EXE with /DYNAMICBASE.
One of the major differences between 64-bit and 32-bit applications on Windows is the size of the virtual address space that is made available to a process. 64-bit applications whose EXE is linked with the /LARGEADDRESSAWARE flag receive 8 TB in Windows 8 (128 TB in Windows 8.1) of virtual address space whereas 32-bit applications only receive 2 GB by default. The limited amount of address space available to 32-bit applications places practical constraints on the amount of entropy that can be applied by ASLR when randomizing the location of memory mappings. Since 64-bit applications do not suffer from these limitations by default, it is possible to significantly increase the amount of entropy that is used by ASLR. The ASLR implementation in Windows 8 takes full advantage of this opportunity by enabling high degrees of entropy for 64-bit applications. Providing higher degrees of entropy can further decrease the reliability of exploits written by an attacker and also makes it less likely that an attacker will be able to correctly guess or brute force an address.
This feature introduces 1 TB of variance into the address that bottom-up allocations start from. This equates to 24 bits of entropy, or a 1 in 16,777,216 chance of guessing the start address correctly. Since heaps, stacks, and most other memory regions are allocated bottom-up, this has the effect of making traditional address space spraying attacks impractical (such as heap and JIT spraying). This is because systems today do not have enough memory available to spray the amount that would be needed to achieve even small degrees of reliability. In addition, executable images that are randomized by the Force ASLR feature receive high degrees of entropy as a result of the high entropy bottom-up randomization feature being enabled for an application. As a result, exploits for vulnerabilities in 64-bit applications that rely on address space spraying will first need to disclose the address at least one bottom-up allocation in order to determine where data may have been placed relative to that address.
For compatibility reasons, this feature is disabled by default and must be enabled on a per-application basis. This is because some 64-bit applications have latent pointer truncation issues that can surface when dealing with pointers above 4 GB (significant bits set beyond bit 31). 64-bit applications that enable this feature are guaranteed to receive memory addresses that are above 4 GB when allocating bottom-up memory (unless insufficient address space exists above 4 GB). 64-bit applications can enable support for this feature by linking their EXE with the /HIGHENTROPYVA linker flag provided by Visual Studio 2012. This flag is enabled by default for native applications when building with Visual Studio 2012 and beyond.
This feature introduces 8 GB of variance into the address that top-down allocations start from. This equates to 17 bits of entropy, or a 1 in 131,072 chance of guessing the start address correctly. 64-bit processes automatically receive high degrees of entropy for top-down allocations if top-down randomization has been enabled (which is controlled by whether the EXE linked with /DYNAMICBASE).
Prior to Windows 8, 64-bit executable images received the same amount of entropy that was used when randomizing 32-bit executable images (8 bits, or 1 in 256 chance of guessing correctly). The amount of entropy applied to 64-bit images has been significantly increased in most cases starting with Windows 8:
The reason that entropy differences exist due to the base address of an image is again for compatibility reasons. The Windows kernel currently uses the preferred base address of an image as a hint to decide if the image supports being based above 4 GB. Images that are based below 4 GB may not have been tested in scenarios where they are relocated above 4 GB and therefore may have latent pointer truncation issues. As such, the Windows kernel makes a best-effort attempt to ensure that these images load below 4 GB. Because of these constraints, the vast majority of 64-bit EXEs and DLLs in Windows 8 and Windows 8.1 have been based above 4 GB to ensure that they benefit from the highest possible degrees of entropy. 64-bit images produced by the Visual C++ tool chain also base images above 4 GB by default.
The effectiveness of ASLR is inherently dependent on an attacker being unable to discover the location of objects in memory. In some cases, an attacker can leverage a vulnerability in a program to disclose information about the address space layout of a process. For example, an attacker could use a vulnerability to read memory that they would not normally be able to access and thereby discover the address of a DLL in memory. While the mechanics of disclosing address space information are typically dependent on the application and vulnerability that are being exploited, there are some general approaches that attackers have identified. In Windows 8, we have taken steps to eliminate and destabilize known address space information disclosure vectors, although these changes have by no means resolved the general problem posed by address space information disclosures.
Windows uses an internal data structure known as SharedUserData to efficiently communicate certain pieces of information from the kernel to all processes on a system. For efficiency and compatibility reasons, the memory address that SharedUserData is located at is consistent across all processes on a system and across all versions of Windows, including Windows 8 (0x7ffe0000). Since Windows XP Service Pack 2, this memory region has contained pointers into a system DLL (NTDLL.DLL) that have been used to enable efficient system call invocation, among other things. The presence of image pointers at a known-fixed location in memory was noted as being useful in the context of certain types of address space information disclosures. In Windows 8 (and now prior versions with MS13-063 installed), all image pointers have been removed from SharedUserData to mitigate this type of attack. The removal of these pointers effectively mitigated a DEP/ASLR bypass that was later disclosed which affected versions of Windows prior to Windows 8 (involving LdrHotPatchRoutine).
Ensuring that all forms of memory allocation have some base level of entropy has the effect of eliminating what would otherwise be predictable memory mappings in the address space. In some cases, an attacker may be able to leverage a vulnerability to read the contents of arbitrary locations in memory. In these cases, the attacker must be able to predict or discover the address of the object that they wish to read from (typically via heap spraying). The improvements that have been made to ASLR in Windows 8 have made it more difficult for attackers to do this reliably, particularly on 64-bit. As a result, any address space information disclosure that relies on reading from a specified location in memory will generally be more difficult and less reliable on Windows 8. It should be noted, however, that the size of the 32-bit address space places practical constraints on the impact of this, particularly in cases where an attacker is able to fill a large portion of the address space with desired content.
While the previous sections highlighted improvements that were made to ASLR for user mode applications, we also made investments in Windows 8.1 into hardening the Windows kernel against disclosing kernel address space information to lesser privileged user mode processes. The majority of these improvements focused on restricting low integrity processes from accessing certain system and process information classes that intentionally expose kernel address space information. In addition, certain kernel addresses were removed from the shared desktop heap and hypervisor-assisted restrictions were added to limit the exposure of kernel addresses via instructions that can be used to query the GDT/IDT descriptor table base addresses. As a result of these improvements, sandboxed applications such as Internet Explorer 11, Microsoft Office 2013, and Windows Store apps are all prevented from discovering addresses through these interfaces. This means it will be more difficult for attackers to exploit local kernel vulnerabilities as a means of escaping these sandboxes.
The improvements that have been made to ASLR in Windows 8 and Windows 8.1 have addressed various limitations that attackers have been taking advantage when exploiting vulnerabilities. As a result of these improvements, we anticipate that attackers will continue to be increasingly reliant on address space information disclosures as a means of bypassing ASLR. Forcing attackers to rely on information disclosures has the effect of adding another costly check box to the conditions that attackers need to satisfy when exploiting memory safety vulnerabilities in modern applications.
- Matt Miller
Today we released eleven security bulletins addressing 24 CVE’s. Five bulletins have a maximum severity rating of Critical while the other six 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.
(GDI+ TIFF parsing)
(Kernel mode drivers)
(hxds.dll ASLR mitigation bypass)
- Jonathan Ness, MSRC's engineering team
Today we released MS13-098, a security update that strengthens the Authenticode code-signing technology against attempts to modify a signed binary without invalidating the signature. This update addresses a specific instance of malicious binary modification that could allow a modified binary to pass the Authenticode signature check. More importantly, it also introduces further hardening to consider a binary “unsigned” if any modification has been made in a certain portion of the binary. Those improvements to the Authenticode Signature Verification, as described below, require changes from a small but important set of third party application developers, so the new process will not be enabled by default today. Six months from today, on June 10, 2014, binaries will be considered unsigned if they do not conform to the new verification process. If you want to enable the regkey and test the change today, Please see the information posted in the security advisory 2915720.
We’d like to use this blog post to share more about Authenticode and the role of Authenticode in enabling customer confidence while running executables downloaded from the internet.
Authenticode and signed binaries
Authenticode® is a digital signature format that is used to determine the origin and integrity of software binaries. Authenticode is based on Public-Key Cryptography Standards (PKCS) #7 signed data and X.509 certificates to bind an Authenticode-signed binary to the identity of a software publisher.
The idea behind Authenticode is to leverage the reputation of a software developer or company to help customers make a trust decision. If you trust a particular company, you can execute binaries published by that company from any source and media as long as the binary is signed with the company’s valid Authenticode signature. The valid Authenticode signature does not guarantee that the software is safe to run. However, it does prove that the binary has been signed by that particular company and has not been altered afterward. According to the Authenticode Portable Executable format specification the Authenticode signatures can be “embedded” in a Windows PE file, in a location specified by the Certificate Table entry in Optional Header Data Directories. When Authenticode is used to sign a Windows PE file, the algorithm that calculates the file's Authenticode hash value excludes certain PE fields. When embedding the signature in the file, the signing process can modify these fields without affecting the file's hash value. These fields are as follows: the checksum, certificate table RVA, certificate table size and the attribute certificate table. The certificate table contains a PKCS #7 SignedData structure containing the PE file's hash value, a signature created by the software publisher’s private key, and the X.509 v3 certificates that bind the software publisher’s signing key to a legal entity. A PKCS #7 SignedData structure can optionally contain:
The following schema illustrates how an Authenticode signature is included in a Windows PE file:
This design philosophy allows no executable code being omitted from the signature. Once the code is authenticated and attributed to an author, everything that code does is the responsibility of the author.
Installer programs and Authenticode signatures
Downloaders and installers signed by Authenticode require special consideration because they download and execute other executables. As explained above, Authenticode testifies that a particular program’s code was signed by the author and that the executable code has not changed since then. If that particular program is designed to download and run a second executable from the network, the original program needs to verify the second executable’s integrity with Authenticode or by other means. The developers of a program should pay close attention to guarantee the same level of trust and integrity across the full download chain to ensure that executables downloaded by their installer are also trustworthy and cannot be replaced with a malicious program.
Microsoft was informed that a small set of third party installer programs, signed with a valid Authenticode signature, had been modified to download a different executable than the one originally designed to download without invalidating the installer’s Authenticode signature.
We analyzed each of these samples to study the execution flow to learn how they worked. Firstly, the code, which is covered by Authenticode, is executed from the entry point. Then, this code looks for an overlay inside the file to read a stream. Finally, the code decrypts a URL from the stream and downloads and executes an executable from that URL. The programs unfortunately omitted the integrity check before executing the downloaded file.
An overlay is data appended to the physical image of a Portable Executable. Explained simply, one can take a PE binary, append additional content to the end without adjusting the header, and it has an overlay. This data area is not defined as part of the image by the PE header and therefore isn't part of the virtual image of the loaded PE. The Authenticode verification code verifies that the Attribute Certificate table is the last thing in the file and report an invalid signature if something is appended after that.
In the sample reported to Microsoft, the size of the certificate directory had been increased to cover the overlay. So technically, the certificate directory was the last thing in the file, allowing the test to pass.
There are couple of lessons to learn from this sample:
First, the developer stored the URL stream intentionally inside the certificate directory to allow them to sign once and create different installers. This particular sub-optimal practice enabled the malicious binary modification reported to Microsoft. The MS13-098 hardening, expected to go into effect June 10, 2014, will consider a binary unsigned in this case going forward.
Second, the developer in this particular case was not validating the file subsequently downloaded and executed by any other means.
A better way to enable the scenario desired by the developer would have been to store the URL as a resource inside the PE. In doing so, the URL would have been covered by Authenticode and any attempt to modify the downloaded URL would have resulted in a failed signature verification.
Today, with MS13-098, as described above, the Windows team has added additional hardening and mitigation in order to detect this kind of bad practices and report an invalid Authenticode signature. When enabled, these hardening measures will detect cases where additional unverified data has been placed after the PKCS #7 blob in the certificate directory of a PE image. The check validates that there is no non-zero data beyond the PKCS #7 structure. Although this change prevents one form of this unsafe practice, it is not capable of preventing all such forms; for example, an application developer can place unverified data within the PKCS #7 blob itself which will not be taken into account when verifying the Authenticode signature. However, as this blog post illustrates, developers are strongly discouraged from doing this as it can lead to unsafe application behavior and could potentially put the reputation of the signing company at risk if their application makes use of the unverified data in an unsafe way.
- Ali Rahbar, MSRC engineering team
I would like to thank the Jonathan Ness, Elia Florio and Ali Pezeshk
Ref : http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx
Today we released MS13-106 which resolves a security feature bypass that can allow attackers to circumvent Address Space Layout Randomization (ASLR) using a specific DLL library (HXDS.DLL) provided as part of Microsoft Office 2007 and 2010.
The existence of an ASLR bypass does not directly enable the execution of code and does not represent a risk by itself, since this bypass still needs to be used in conjunction with another higher-severity vulnerability that allows remote code execution in order to provide some value to attackers. ASLR is an important mitigation that has been supported since Windows Vista which, when combined with Data Execution Prevention (DEP), makes it more difficult to exploit memory corruption vulnerabilities.
Because ASLR is a generic mitigation aimed at stopping exploitation techniques that apply to many vulnerabilities, attackers are very interested in attempting to find new bypass techniques for it. These bypass techniques typically fall into one of three categories:
1) Presence of a DLL at runtime that has not been compiled with /DYNAMICBASE flag (therefore loaded at a predictable location in memory).
2) Presence of predictable memory regions or pointers that can be leveraged to execute code or alter program behavior.
3) Leveraging a vulnerability to dynamically disclose memory addresses.
The ASLR bypass that has been addressed by MS13-106 falls into the first category. The difficulty of finding and using an ASLR bypass varies based on the category of the technique. It is generally easier to identify DLL modules that fall into the first category (especially expanding the search through third-party browser plugins and toolbars), while it is generally more difficult, and less reusable, to find or create a bypass for the other two categories. For example, two of the recent Internet Explorer exploits that were used in targeted attacks (CVE-2013-3893 and CVE-2013-3897) both relied on the same ASLR bypass, which fell into the first category -- making use of the HXDS.DLL library that is part of Office 2007/2010 that was not compiled using /DYNAMICBASE.
Bolstering the effectiveness of ASLR helps to harden the security of our products and that is why MSRC continues to releasetools and updates that enforce ASLR more broadly on Windows (such as KB2639308 and EMET) and to release updates that close known ASLR bypasses as part of our defense-in-depth strategy (such as MS13-063 for the bypass presented atCanSecWest 2013).
Today MS13-106 closes one additional known bypass that will no longer be available to attackers.
- Elia Florio, MSRC Engineering
In June 2013, we released EMET 4.0 and customer response has been fantastic. Many customers across the world now include EMET as part of their defense-in-depth strategy and appreciate how EMET helps businesses prevent attackers from gaining access to computers systems. Today, we’re releasing a new version, EMET 4.1, with updates that simplify configuration and accelerate deployment.
EMET anticipates the most common techniques adversaries might use and shields computer systems against those security threats. EMET uses security mitigation technologies such as Data Execution Prevention (DEP), Mandatory Address Space Layout Randomization (ASLR), Structured Exception Handler Overwrite Protection (SEHOP), Export Address Table Access Filtering (EAF), Anti-ROP, and SSL/TLS Certificate Trust Pinning, to help protect computer systems from new or undiscovered threats. EMET can also protect legacy applications or third party line of business applications where you do not have access to the source code.
Today’s EMET 4.1 release includes new functionality and updates, such as:
EMET built by Microsoft Security Research Center (MSRC) engineering team, brings the latest in security science to your organization. While many EMET users exchange feedback and ideas at TechNet user forums, a less known fact is that Microsoft Premier Support options are also available for businesses that deploy EMET within their enterprise. Many of our customers deploy EMET - at scale - through the Microsoft System Center Configuration manager and apply enterprise application, user and accounts rules through Group Policy. EMET works well with the tools and support options our customers know and use today.
As we continue to advance EMET, we welcome your feedback on what you like and what additional features would help in protecting your business. If you are attending RSA Conference at San Francisco, or the Blackhat Conference in Las Vegas next year, be sure to stop by the Microsoft booth, and share your feedback with us. We look forward to hearing from you.
Over the weekend we became aware of an active attack relying on an unknown remote code execution vulnerability of a legacy ActiveX component used by Internet Explorer. We are releasing this blog to confirm one more time that the code execution vulnerability will be fixed in today’s UpdateTuesday release and to clarify some details about the second vulnerability reported.
The attack was disclosed to us by our security partners and it’s the typical targeted attack exploited through a specific “drive-by” legitimate website that was compromised to include an additional piece of code added by the attackers. At the moment we have analyzed samples from the active attack that are targeting only older Internet Explorer versions running on Windows XP (IE7 and 8) because of the lack of additional security mitigations on those platforms (Windows 7 is affected but not under active attack). EMET was able to proactively mitigate this exploit.
The exploit was created combining two distinct vulnerabilities, but with different impact and severity ratings:
The remote code execution vulnerability with higher severity rating will be fixed immediately in today’s Patch Tuesday and we advise customers to prioritize the deployment of MS13-090 for their monthly release. As usual, customers with Automatic Updates enabled will not need to take any action to receive the update and will be automatically protected.
The information disclosure vulnerability does not allow remote code execution and so it has a lower security rating since it will be typically used in combination with other high-severity bug (like it happened with CVE-2013-3918) to improve effectiveness of exploitation. Also, this vulnerability requires attackers to have prior knowledge of path and filenames present on targeted machines in order to be successfully exploited. This vulnerability was not used to bypass ASLR, but simply to remotely determine the exact version of a certain DLL on disk in order to build a more precise ROP payload (it’s a local information disclosure rather than a memory address disclosure).
We are still investigating the impact and root cause of the information disclosure vulnerability and we may follow up with additional information and mitigations as they become available.
Elia Florio – MSRC Engineering