Control Flow Guard ( CFG ) will no longer be included in the list of in-scope mitigations, according to a change to the Mitigation Bypass Bounty that was announced today. We’ll give more background and explain why we’re making this change in this blog post.
Background for Mitigation Bypass Bounty
By learning about bypasses, Microsoft established the Mitigation Bypass Bounty in 2013 with the intention of assisting us in developing essential defense-in-depth mitigation technologies. We have fixed numerous bypasses that have been reported in our exploit mitigations since launching this program, and we intend to increase that number in the future.
Giving researchers clear instructions on what kinds of issues are within the scope of the Mitigation Bypass bounty program and what kind of cash reward can be anticipated is one of its difficulties. In an effort to make things better here, we’ve made a number of changes over the past few years, including:
- Payout tiers for various mitigation bypass types ( i .e., bugs vs. design issues ) are more precisely defined.
- Researchers can better understand the kinds of problems we are currently aware of by being more open about them.
We continue to take feedback and make adjustments to be more researcher-friendly despite these changes because we are aware of our shortcomings.
Impact of mitigation measures on exploration
The occurrence of vulnerabilities being exploited in the wild is one datapoint that Microsoft keeps an eye on. Over the past eight years, Microsoft has observed a steady decline in the number of vulnerabilities exploited.
We think that the rising level of exploitation difficulty, which has a temporary impact on the economics of vulnerability exploit, contributes to the decline in known exploits in the wild. We credit Microsoft’s ongoing investment in exploit mitigation technologies like CFG, Arbitrary Code Guard (ACG), Code Integrity Guard, MemGC, and others for a significant portion of the increased difficulty.
We relied more on examining wild exploits to find mitigation opportunities before we started the Mitigation Bypass Bounty. This caused a delay between the availability of mitigation and the use of techniques in the wild. We established the Mitigation Bypass Bounty to actively research bypasses before they were put to use in the wild in order to reduce this delay.
Security researchers have been particularly interested in CFG as a mitigation bypass bounty target. We now know a lot about the various bugs and design restrictions that affect CFG thanks to this research. This has led us to reconsider the threat model that requires stronger CFI defense. We are aware that in order to achieve this, we will need to expand and enhance CFG’s design, such as with finer-grained CFI, read-only memory protection, safe unwind/exception handling, etc. We recently discussed the difficulties CFG faces and the development of our threat model ( Video | Slides ).
For other Mitigation Bypass Bounty targets, like ACG, Microsoft has also received submissions and made adjustments. Researchers can anticipate adding new mitigations as bounty targets as we develop them.
The mitigation bypass bounty scope has changed.
As of today, CFG is no longer included in the Mitigation Bypass Bounty’s set of in-scope mitigations. We think we now fully comprehend CFG’s restrictions and the threat model to which the design must be modified. We would prefer that researchers concentrate their attention on the other in-scope mitigations for the bounty rather than continuing our research into CFG bypasses until we have addressed these limitations. We do n’t intend to remove or deprecate CFG from the bounty scope, but we still think it’s a useful defense-in-depth mitigation. Once CFG has been improved, we anticipate bringing it back into focus.
As always, we would value the community’s opinions on this or any other pertinent issues.
Bialek, Joe
Team for mitigation, MSRC Vulnerabilities &