Bug Bounty Policy Changes#17216
Conversation
- Half memory corruption payouts - Clarify that UXSS requires an uncompromised content process - Remove the static analysis bug bounty
|
|
||
| <p>The bounty program encourages the <u>earliest possible reporting</u> of potentially exploitable bugs. A bounty <u>is not determined based on the <i>initial</i> submission</u>, but rather on the outcome of the discussion with developers. Improving test cases post-submission, figuring out if an engineer's speculation is founded or not, or other assistance that helps resolve the issue <i>will</i> increase your bounty payout. <u>However</u>, words have dminishing returns, and excessive comments (typically AI-generated) decrease the value of the report. Reproduction testcases provide more value than descriptions. Additionally, a report should not have severity keywords set or include CVSS scores.</p> | ||
|
|
||
| <p>Typically bounties are not paid for issues which cannot be identified/fixed from the report. While we do adhere to a first reporter-rule (with a 48-hour collision window), exceptions are made for reports that are not actionable and require additional information provided by another party. </p> |
There was a problem hiding this comment.
| <p>Typically bounties are not paid for issues which cannot be identified/fixed from the report. While we do adhere to a first reporter-rule (with a 48-hour collision window), exceptions are made for reports that are not actionable and require additional information provided by another party. </p> | |
| <p>Typically bounties are only paid for issues which can be identified/fixed from the report. While we do adhere to a first reporter-rule (with a 48-hour collision window), exceptions are made for reports that are not actionable and require additional information provided by another party. </p> |
| </tbody> | ||
| </table> | ||
|
|
||
| <p>Note that because advances in vulnerabilitiy detection techniques have made these easier to discover, memory corruption based vulnerabilities, as well as those that can be discovered by an ASAN build, will now be paid at half the rate of the category.</p> |
There was a problem hiding this comment.
| <p>Note that because advances in vulnerabilitiy detection techniques have made these easier to discover, memory corruption based vulnerabilities, as well as those that can be discovered by an ASAN build, will now be paid at half the rate of the category.</p> | |
| <p><strong>Note</strong> that because advances in vulnerabilitiy detection techniques have made these easier to discover, memory corruption based vulnerabilities, as well as those that can be discovered by an ASAN build, will now be paid at half the rate of the category.</p> |
Should we add a "for now" or "temporarily"?
There was a problem hiding this comment.
I like making "Note" bold as Freddy suggested, but if we do that the change of emphasis makes the sentence wonky without changing the punctuation. "Note that because..." would have to be "Note: because..." (or maybe a comma, but that seems really old-fashioned).
There was a problem hiding this comment.
Substantively, are we really just whacking all our up-to-now normal sec-high bugs in half? Will people just try to hide the fact they used ASAN? you do cover that generally as "memory corruption based vulnerabilities". Unless we tell people how they can improve their report to get back to full value it would be more honest to just lower our published bounty ranges. [upd: which you did by adding a sub-category showing the lower range]
I don't think the problem is "ASAN", it's evidence of memory corruption without evidence of control or other usefulness. So a random ASAN OOB read is meh, but if you show me (in your POC, not hand-waving) that you can get that extra memory back into your web page to do something with it then maybe that starts looking like a sec-high again. Or an ASAN UAF, but with a testcase that shows you can control a read or jump address.
When we talked about it making these changes I thought that's how you meant to evaluate these, but the way this change is written seems to slam the door on it. I worry it will discourage reporters from bothering to look for bugs at ll, instead of encouraging them to put more effort into proving the bugs they found were more important to fix. It's not the straightforward ASAN bugs I want to discourage, it's the fluffy AI crap where we have to work to figure out what they're claiming.
|
FWIW, I approve of this landing asap. We can figure out the minor details later. None of my comments are blocking. :) |
dveditz
left a comment
dveditz
left a comment
There was a problem hiding this comment.
I may have misunderstood the conclusion about what changes we were going to make to the program.
| <td> | ||
| • UXSS<sup>2</sup> | ||
| </td> | ||
| <td>$10,000</td> |
There was a problem hiding this comment.
I'd still like to see these be converted to "up to $10,000" with no bottom range, and ditto the $20,000 sandbox one. I know in practice we have awarded bounties below the bottom because they are "not quite a full example of that type of bug", but I think it just sets us up for more arguing with the reporter over a binary "it is too a UXSS bug so it's at least 8k", with us having to be defensive about "we didn't mean ones where the victim has to open an obscure dialog and then type ↑↑↓↓←→←→BA".
Yes, we have a footnote explaining we might pay lower in certain circumstance, but I don't like "The big print giveth, and the small print taketh away". Let people see the real range in the chart, and use the footnote to explain the circumstances that take away from the top-line.
I'm commenting here on a line you did not change because this is not quite related to the other changes you are making, although there is a footnote edit related to the UXSS category. In the other cases you've added new sub-categories with their own lower ranges which is another way to do it.
| </tbody> | ||
| </table> | ||
|
|
||
| <p>Note that because advances in vulnerabilitiy detection techniques have made these easier to discover, memory corruption based vulnerabilities, as well as those that can be discovered by an ASAN build, will now be paid at half the rate of the category.</p> |
There was a problem hiding this comment.
I like making "Note" bold as Freddy suggested, but if we do that the change of emphasis makes the sentence wonky without changing the punctuation. "Note that because..." would have to be "Note: because..." (or maybe a comma, but that seems really old-fashioned).
| </tbody> | ||
| </table> | ||
|
|
||
| <p>Note that because advances in vulnerabilitiy detection techniques have made these easier to discover, memory corruption based vulnerabilities, as well as those that can be discovered by an ASAN build, will now be paid at half the rate of the category.</p> |
There was a problem hiding this comment.
Substantively, are we really just whacking all our up-to-now normal sec-high bugs in half? Will people just try to hide the fact they used ASAN? you do cover that generally as "memory corruption based vulnerabilities". Unless we tell people how they can improve their report to get back to full value it would be more honest to just lower our published bounty ranges. [upd: which you did by adding a sub-category showing the lower range]
I don't think the problem is "ASAN", it's evidence of memory corruption without evidence of control or other usefulness. So a random ASAN OOB read is meh, but if you show me (in your POC, not hand-waving) that you can get that extra memory back into your web page to do something with it then maybe that starts looking like a sec-high again. Or an ASAN UAF, but with a testcase that shows you can control a read or jump address.
When we talked about it making these changes I thought that's how you meant to evaluate these, but the way this change is written seems to slam the door on it. I worry it will discourage reporters from bothering to look for bugs at ll, instead of encouraging them to put more effort into proving the bugs they found were more important to fix. It's not the straightforward ASAN bugs I want to discourage, it's the fluffy AI crap where we have to work to figure out what they're claiming.
| <p><sup>1</sup> For Highest Impact, bypassing WebExtension Install Prompts excludes local attacks.</p> | ||
|
|
||
| <p><sup>2</sup>UXSS is defined as the ability to execute JavaScript in an arbitrary cross-origin context. As mentioned above, complex user interaction or limited capabilities of the vulnerability (such as only being able to inject into a cross-origin domain, but not an arbitrary cross-origin domain) may decrease the bounty award.</p> | ||
| <p><sup>2</sup>UXSS is defined as the ability to execute JavaScript in an arbitrary cross-origin context. As mentioned above, complex user interaction or limited capabilities of the vulnerability (such as requiring a compromised content process, or only being able to inject into a cross-origin domain but not an arbitrary cross-origin domain) may decrease the bounty award.</p> |
There was a problem hiding this comment.
| <p><sup>2</sup>UXSS is defined as the ability to execute JavaScript in an arbitrary cross-origin context. As mentioned above, complex user interaction or limited capabilities of the vulnerability (such as requiring a compromised content process, or only being able to inject into a cross-origin domain but not an arbitrary cross-origin domain) may decrease the bounty award.</p> | |
| <p><sup>2</sup>UXSS is defined as the ability of web content to execute JavaScript in an arbitrary cross-origin context. As mentioned above, complex user interaction or limited capabilities of the vulnerability (such as only being able to inject into specific domains but not an arbitrary cross-origin one) may decrease the bounty award. If the UXSS requires a compromised content process then to qualify for Higher Impact the submission must have a POC that includes a novel content process RCE vulnerability.</p> |
|
Holding off merging as it's unclear if waiting for @dveditz's more recent comments is a blocker. @mozfreddyb If you need this merged ASAP today (Monday) let me know, np |
4 participants
@dveditz @mozfreddyb @simon-friedberger