In the past, exploits had to be fully functional to be rewarded at our highest tier, high-quality report with functional exploit. Demonstration of how a bug might be exploited is one factor that the panel may use to determine that a report is high-quality, our second highest tier, but we want to encourage more of this type of analysis. This information is very useful for us when planning future mitigations, making release decisions, and fixing bugs faster. We also know it requires a bit more effort for our reporters, and that effort should be rewarded. For the time being this only applies to V8 bugs, but we’re curious to see what our reporters come up with!
The full details are available on the Chrome VRP rules page. At a high-level, we’re offering increased reward amounts, up to double, for qualifying V8 bugs.
The following table shows the updated reward amounts for reports qualifying for this new bonus. These new, higher values replace the normal reward. If a bug in V8 doesn’t fit into one of these categories, it may still qualify for an increased reward at the panel’s discretion.
 Baseline reports are unable to meet the requirements to qualify for this special reward.
So what does a report need to do to demonstrate that a bug is likely exploitable? Any V8 bug report which would have previously been rewarded at the high-quality report with functional exploit level will likely qualify with no additional effort from the reporter. By definition, these demonstrate that the issue was exploitable. V8 reports at the high-quality level may also qualify if they include evidence that the bug is exploitable as part of their analysis. See the rules page for more information about our reward levels.
The following are some examples of how a report could demonstrate that exploitation is likely, but any analysis or proof of concept will be considered by the panel:
- Executing shellcode from the context of Chrome or d8 (V8’s developer shell)
- Creating an exploit primitive that allows arbitrary reads from or writes to specific addresses or attacker-controlled offsets
- Demonstrating instruction pointer control
- Demonstrating an ASLR bypass by computing the memory address of an object in a way that’s exposed to script
- Providing analysis of how a bug could lead to type confusion with a JSObject
We’d like to thank all of our VRP reporters for helping us keep Chrome users safe! We look forward to seeing what you find.
-The Chrome Vulnerability Rewards Panel
This post appeared first on Google Online Security Blog
Author: Scott Westover