Mitigation Bypass and Bounty for Defense Terms

Updated October 1, 2018

PROGRAM DESCRIPTION

Microsoft is pleased to announce the launch of the Microsoft Mitigation Bypass Bounty and Bounty for Defense Program beginning June 26, 2013. Through this program, individuals across the globe have the opportunity to submit a novel mitigation bypass against our latest Windows platform, and are also invited to submit a defense idea that would block an exploitation technique that currently bypasses the latest platform mitigations. Under this program, qualified mitigation bypass submissions are eligible for payment of up to $100,000 USD and qualified defensive techniques are eligible for a bounty of up to $100,000, for a total of up to $200,000 USD. All bounties will be paid out at Microsoft’s discretion.

If you are submitting a new mitigation bypass technique that you have found in an active attack, please note that that we have a similar but separate program for you, and the terms appearing here are aimed at individuals submitting their own idea for a new mitigation bypass technique.

If you are submitting your own idea, please read the full terms below and then send your entry for consideration to secure@microsoft.com. If you are submitting a technique you found in use in an active attack, you must first pre-register with us by emailing us at bounty@microsoft.com and secure@microsoft.com for further details.

WHAT CONSTITUTES AN ELIGIBLE SUBMISSION FOR MITIGATION BYPASS?

Eligible bypass submissions will include a white paper or a brief document explaining the exploitation method and target one of the following scenarios:

A novel method of exploiting a real Remote Code Execution (RCE) vulnerability. A real RCE vulnerability is understood to be an RCE that exists in a Microsoft application which may or may not have already been addressed through a security update.
A novel method of bypassing a mitigation imposed by a user mode sandbox. For example, this could include a technique that can bypass symbolic link restrictions imposed by a sandbox or other novel logic issues that enable an attacker to escape the sandbox and elevate privileges.

Eligible bypass submissions are permitted to make use of known methods of exploitation in their exploit and whitepaper, but a novel exploitation method must be an integral and required component of enabling reliable remote code execution. Submissions must clearly distinguish the novel aspects of the exploitation method being described.

It is recommended that submissions target 64-bit user mode applications or applications that run on 32-bit ARM processors.

Eligible bypass submissions must be able to exploit a user mode application that makes use of all the latest mitigations supported by the Windows platform. Refer to the section on MITIGATION BYPASS SCOPE for more information on what is considered in scope and out of scope for mitigation bypass submissions.

Eligible bypass submissions must demonstrate and describe an exploitation method that meets the following criteria:

Generic: RCE exploitation methods must be applicable to one or more common memory corruption vulnerability classes.
Reliable: it must have a low probability of failure.
Reasonable: it must have reasonable requirements and pre-requisites.
Impactful: it must be applicable to high risk application domains (browsers, document readers, etc).
User Mode: RCE exploitation methods must be applicable to user mode applications.
Latest Version: it must be applicable to the latest version of our products on the date the entry is submitted.
Novel: it must be a novel and distinct method that is not known to Microsoft and has not been described in prior works.

All qualified submissions are eligible to receive up to $100,000 USD. Submissions with a proof of concept, functioning exploit, detailed write up and/or a whitepaper will be eligible for higher rewards.

WHAT CONSTITUTES AN ELIGIBLE BOUNTY FOR DEFENSE SUBMISSION?

Bounty for Defense submissions (“defense submissions”) provided to Microsoft must meet the following criteria to be eligible under this program:

Eligible defense submissions will include a technical whitepaper to describe the defense idea that could effectively block an exploitation technique that currently bypasses either the latest platform mitigations or a defensive submission that blocks exploits that is not in the latest platform.

Qualified defense submissions are eligible to receive bonus of up to $100,000 USD, depending on the quality and uniqueness of the defense idea.

We reserve the right to reject any submission that we determine, in our sole discretion, does not meet the above criteria.

Background and descriptions on Windows platform mitigations can be found in the whitepaper on Mitigating Software Vulnerabilities.

MITIGATION BYPASS SCOPE

The following tables provide a list of the user mode mitigations that are explicitly in scope and the definition of the techniques that are in scope and out of scope for each mitigation. Submissions that leverage other novel exploitation techniques that are not considered out of scope and are not listed below may still qualify for a bounty. An eligible bypass submission must work when all supported mitigations in the latest WIP fast build are enabled. This means a submission must assume that mitigations such as DEP, ASLR, CIG, ACG, and so on are all enabled by the target application even if they are not currently enabled by default in all scenarios at the time of submission.

This scope is subject to change at any time at Microsoft’s discretion.

Control-flow integrity mitigations

The following mitigations support Microsoft’s control-flow integrity protections.

Mitigation	In scope	Out of scope
Data Execution Prevention (DEP)	Techniques that make it possible to execute code from non-executable memory in a process that has enabled DEP (always on)	Reuse of already executable code

Code integrity mitigations

Mitigation	In scope	Out of scope
Arbitrary Code Guard (ACG)	Techniques that make it possible to dynamically generate or modify code in a process that has enabled the ProcessDynamicCodePolicy(ProhibitDynamicCode = 1).	Bypasses that rely on thread opt out being enabled(AllowThreadOptOut = 1).
Code Integrity Guard (CIG)	Techniques that make it possible to load an improperly signed binary into a process that has enabled code signing restrictions(e.g. ProcessSignaturePolicy).	In-memory injection of unsigned image codepages

Supporting mitigations

Mitigation	In scope	Out of scope
Child Process Policy	Techniques that make it possible to spawn a child process from a process that has restricted child process creation (via the child process policy).
Address Space Layout Randomization (ASLR)	Techniques that make it possible to generically bypass ASLR in 64-bit applications that enable High Entropy ASLR and Force Relocate Images.	Individual vulnerabilities that enable address space information disclosure Address inference via GC 32-bit ASLR bypasses
SEHOP/SafeSEH	Techniques that can be used to hijack control-flow by corrupting an SEH registration record in a process/image that enables SEHOP and Safe SEH	Techniques that assume knowledge of where a stack is located Techniques that rely on non-Safe SEH images
Heap randomization & metadata protection	Techniques that can be used to achieve reliable metadata corruption or user data corruption.

MITIGATION BYPASS PAYOUT TIERS

The following table describes the payout tiers for qualifying mitigation bypass submissions.

Tier	Description	Applicable Mitigations	Proof of concept	Report Quality	Maximum Payout range (USD)
Tier 1	Novel & fundamental advancement in exploitation technology that universally bypasses current mitigations	N/A	Required	High Low	$100,000 $50,000
Tier 2	Design-level mitigation bypass	Control-flow integrity mitigations Code integrity mitigations	Required	High Low	$45,000 $20,000
Tier 3	Implementation or bug-level mitigation bypasses	Control-flow integrity mitigations Code integrity mitigations Supporting mitigations	Required	High Low	$15,000 $5,000

Additional factors that are considered when assessing payouts include: how broadly applicable the bypass may be, the perceived level of difficultly and reliability in making use of the bypass, and the overall impact of the mitigation bypass

LEGAL NOTICE

To get additional information on the Microsoft legal guidelines please go here.

Thank you for participating in the Microsoft Bug Bounty Program!

Revision History

Jan 31, 2017: Return Flow Guard experimental mitigation was removed from the list of in scope mitigations
Oct 27, 2017: “Bypasses that rely on race conditions or exception handling” and “Bypasses that rely on thread suspension” were added to the list of “Out of scope” for “Control Flow Guard (CFG)” Mitigations.
Jan 23rd, 2018: Instances of missing CFG instrumentation prior to an indirect call added to “Out of Scope” for “Control Flow Guard (CFG)” Mitigations.
March 20, 2018: "Code replacement attacks" explicitly added to "Out of Scope" for "Control Flow Guard" mitigations.
June 21, 2018: Remove Control Flow Guard from the list of in scope mitigations
August 7, 2018: Accidentally re-introduce Control Flow Guard to bounty scope
October 2, 2018: Remove Control Flow Guard from the list of in scope mitigations (fix above publishing error)