Today we announced the upcoming Mitigation Bypass Bounty, the BlueHat Bonus for Defense, and the Internet Explorer 11 Preview Bug Bounty program. It’s very exciting to finally take the wraps off of these initiatives and we are anticipating some great submissions from the security research community! These programs will allow us to reward great work by researchers and improve the security of our software – all to the benefit of our customers. Also, we just like to analyze and fix cool bugs!
Security features such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) have made it increasingly difficult and costly to exploit vulnerabilities on modern systems. As a consequence of this, good exploitation techniques that work reliably when exploiting vulnerabilities on modern systems have become increasingly valuable. By learning about novel exploitation techniques, we can design better defenses that help protect our customers even when they are running software with an unknown vulnerability or a vulnerability that has not yet been addressed through a security update. This is why we are announcing the Mitigation Bypass Bounty program.
Anatomy of a good report
A high quality submission to the mitigation bypass bounty program will describe and demonstrate a truly novel method of exploiting one or more memory corruption vulnerability classes when all modern mitigations are in place (e.g. DEP, ASLR, SEHOP, and so on). For a submission to eligible, it must include a detailed whitepaper and a functioning exploit which demonstrates the exploitation technique against a real world remote code execution vulnerability. The technique must also meet a high bar: it must be generic and reliable, it must have reasonable requirements, it must apply to a high-risk user mode application domain, and it must be applicable to the latest version of our products. The complete set of requirements can be found in the official rules.
A good example of an exploitation technique that could have qualified for the mitigation bypass bounty program is JIT spraying. This technique was publicly described for the first time in 2010 by Dionysus Blazakis. It outlined a method of leveraging a Just-In-Time compiler to generate large amounts of partially controlled instructions that could enable alternative instruction streams if executed at a misaligned offset. As a result, an attacker can implicitly bypass DEP and ASLR and thereby more easily exploit many classes of memory corruption vulnerabilities. In response to this exploitation technique, multiple software vendors have released JIT compilers that include built-in mitigations for JIT spraying.
BlueHat Bonus for Defense
In addition to encouraging researchers to report novel exploitation techniques, we also want to encourage submissions to include recommendations on how an exploitation technique can be mitigated. Submissions that include a whitepaper that describes an effective, practical, and robust mitigation for a qualifying exploitation technique may qualify for up to an additional $50,000 USD bonus.
The Security Research and Defense team worked with the core bounty program team to develop the bounty program bug bar for the Internet Explorer 11 Preview Bug Bounty:
Proof of concept
Base Payout Tier
Important or higher severity design-level vulnerability
Proof of Concept is
Eligible security bugs that also have privacy implications
ASLR Info Disclosure Vulnerability
Sandbox Escape Vulnerability
More detail on the submission criteria is available in the official guidelines. One area worth highlighting is our additional focus on eligible security bugs that also have privacy implications. While these bugs would be considered as vulnerabilities in their own right, we thought it was important to highlight them and actively incentivize research that furthers our longstanding commitment to privacy.
The quality and completeness of a submission determines not only the payout but also the priority in which it will be reviewed. High quality submissions should include a detailed analysis of a vulnerability’s root cause in addition to a proof of concept that reliably reproduces the issue. This information helps us rapidly confirm your findings so that you can get paid!
The highest rewards will go to submissions that include a fully functioning exploit which concretely demonstrates that remote code execution is possible. This means the exploit must be capable of bypassing exploit mitigations such as DEP and ASLR. These submissions allow us to study the exploitation techniques that were used to achieve code execution and thereby identify opportunities for new exploit mitigation features. In this way, we can increase the cost and difficulty of exploiting entire classes of vulnerabilities rather than simply addressing a single vulnerability at a time.
The SRD team is also responsible for technical triage on issues as they come in. We’ve invited several security researchers on contract with Microsoft to help us in this effort. Our current roster of analysts is as follows:
We are currently aiming to provide feedback and confirmation of payout within two weeks of a report.
Finally, please remember that the IE11 Preview Bug Bounty runs between June 26 and July 26, 2013, so make sure to get your reports wrapped up and submitted in time.
We are incredibly excited to get these programs underway and are really looking forward to seeing the submissions that come in.
- Matt Miller and David Ross, SRD Bloggers
*Postings are provided "AS IS" with no warranties, and confer no rights.*
We are pleased to announce that the final release of version 4.0 of the Enhanced Mitigation Experience Toolkit, best known as EMET, is now finally available for download. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=39273.
We already mentioned some of the new features introduced in EMET 4: Certificate Trust, mitigations improvement hardening, and the Early Warning Program. During our beta period we added new features and solved application compatibility issues that have been reported both externally and internally. Below is a summary of the changes and enhancements:
Redesigned User Interface: We realized that with the addition of the new features introduced in EMET 4.0 Beta, the old graphical user interface was not as effective and easy to use. For this reason, we decided to re-design EMET’s GUI to facilitate and streamline the configuration operations. We also added the possibility to select the look-and-feel of EMET from a set of skins that we included. Finally, the new user interface is accessible and will change automatically according to your system settings:
Configuration Wizard: We know that configuration can be challenging when installing EMET for the first time. In EMET 3.0 we added the Protection Profiles, which were used to facilitate the initial configuration for applications. With EMET 4.0 we are introducing a Configuration Wizard that will automatically configure EMET with a standard set of SSL certificate pinning rules as well as a list of applications to protect. It also can preserve existing EMET 3.0 settings, and gives the possibility to add standard configuration for the new features. The Configuration Wizard will start automatically during EMET’s installation and can also be accessed, at any time, from EMET GUI. Advanced users can choose to apply a standard configuration through the Configuration Wizard and then customize EMET’s configuration afterwards according to their needs.
Changes in Certificate Trust: We made a few changes to the Certificate Trust feature, based on users’ feedback, further internal investigation, and partnership with third party online services. We added a new exception to the SSL certificate pinning rules that if enabled will make EMET verify just the Public Key component of the Root CAs present in the rule without matching subject name and serial number. Additionally, we made the Certificate Trust feature available on 64-bit versions of Internet Explorer. Finally, we added to the previous default rules for Microsoft online services new rules also for Twitter, Facebook, and Yahoo!.
Updated Group Policy profiles: Enterprise customers will notice that we updated our Group Policy profiles to include not only the ability to configure system and application mitigations, but also the reporting mechanisms, the advanced mitigation configurations, and the exploit action.
If you have EMET 4.0 Beta or EMET 3.5 Technical Preview installed on the system, you will need to uninstall them before installing EMET 4.0, and you will need to remove EMET’s configuration from the registry, by deleting the registry hives HKLM\Software\Microsoft\EMET and, if existing, HKLM\Software\Policies\Microsoft\EMET. If you have EMET 3.0 installed on the system, you don’t need to uninstall it before installing EMET 4.0. The previous version will be uninstalled and at the end of the installation you’ll have the opportunity to migrate the existing settings or to reset EMET configuration with the new default settings.
We want to thank those of you that downloaded EMET 4.0 Beta in the past two months and that provided valuable feedback that greatly helped us finalize EMET 4.0. In particular, we want to thank the Yang Yu from NSFocus security team that reported a technique that allowed to bypass EMET’s protections, and Adam Langley and Cem Paya from Google for feedback on the Certificate Trust feature. As said, we received many, many emails, and it would be impossible to name all the people that provided feedback for EMET 4.0 Beta. You know who you are, and we really appreciated your effort in testing EMET and reaching out to us to provide feedback. Again, thank you!
We truly hope that you enjoy all the new features that we introduced in EMET 4.0. We will continue working on improving EMET to provide better and better protections against internet attacks for customers and to make it even more user friendly and easy to use.
- The EMET Team: Ali Rahbar, Chengyun Chu, Cristian Craioveanu, Dan Beenfeldt, Elia Florio, Elias Bachaalany, Gerardo Di Giacomo, Jonathan Ness, Matt Miller, Neil Sikka, Nitin Kumar Goel, Ken Johnson
MS13-051 addresses a security vulnerability in Microsoft Office 2003 and Office for Mac. Newer versions of Microsoft Office for Windows are not affected by this vulnerability, but the newest version of Office for Mac (2011) is affected. We have seen this vulnerability exploited in targeted 0day attacks in the wild. In this blog we’ll cover the following aspects:
In the Office PNG file parsing code, there is a vulnerability where the length field of a chunk is not correctly checked. The PNG specification (http://www.w3.org/TR/PNG/#5Chunk-layout) says “Although encoders and decoders should treat the length as unsigned, its value shall not exceed 2^31-1 bytes.” However, in the malicious PNG files, we found the length field of a chunk equal to 0xFFFFFFFF. The PNG parsing code correctly treated this field as unsigned (as specified in the PNG spec), but was not catching the case when the value was 0xFFFFFFFF, which if interpreted as an unsigned value, exceeds 2^31-1. Below is what the malicious chunk size looks like (highlighted in yellow):
Shellcode analysis shows that the exploit for this vulnerability was a classic stack based buffer overflow, which wrote far past the end of a buffer on the stack, thereby overwriting control data on the program’s stack, eventually leading to high-jacking the program’s execution. Older versions of Office/Windows don’t have mitigations for these types of exploits, but newer versions of Office/Windows do. This is an example of how running current software can increase an organization’s security. We verified also that EMET 3.0 (and above) is able to stop the exploits observed so far, providing an additional mitigation against this specific attack.
The attacks we observed were extremely targeted in nature and were designed to avoid being investigated by security researchers. The malicious samples observed are Office documents (Office 2003 binary format) which do not include the malicious PNG file embedded directly in the document. Rather, the documents reference a malicious PNG file loaded from Internet and hosted on a remote server.
Attackers also equipped their servers with scripts which avoid serving the PNG exploit multiple times, in an effort to keep this 0day more concealed. We believe that the limited attacks observed were geographically located mostly in Indonesia and Malaysia.
Advice for Detection
The common pattern for all these documents is the filename “space.gif” used by each malicious file to fetch the remote PNG file containing the exploit. In order to help security vendors and enterprises look for potential indicators and to deliver an effective protection, we are providing some of the URLs used to load the remote PNG exploit and hashes of the malicious Office binary format documents observed in these limited targeted attacks.
Thanks to Andrew Lyons and Neel Mehta of Google Inc for the report, and to Elia Florio and Cristian Craioveanu for helping with this case.
- Neil Sikka, MSRC Engineering @neilsikka
Today we released five security bulletins addressing 23 CVE’s. One bulletin has a maximum severity rating of Critical, and four 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.
- Jonathan Ness, MSRC Engineering