Client Bug Bounty Program

Introduction

The Mozilla Client Security Bug Bounty Program is designed to encourage security research in Mozilla software and to reward those who help us create the safest Internet software in existence.

Guidelines: Our general eligibility requirements apply to the Client Bug Bounty Program. Submissions must be either a security bug demonstrating the ability to perform an unauthorized action or obtain access to otherwise-restricted information or an exploit mitigation bypass. We recommend that you read our Frequently Asked Questions before submitting.

Security Vulnerability Bounty

Mozilla will pay a bounty for client security bugs as detailed below. All security bugs must follow the following general criteria to be eligible:

• Eligible security bugs may be present in any of the main development or released versions of Firefox, Firefox for Android, or Firefox for iOS as released by Mozilla Corporation (e.g. Nightly mozilla-central or Beta test versions, as well as the final release product versions). End-of-life products are not eligible for a security bug bounty and non-default configurations are only sometimes eligible.
• Submissions should be made following our instructions below.
• We reserve the right not to pay bounties for security bugs in or caused by additional third party software (e.g. binary plugins, extensions) not bundled by Mozilla in a release.
• We typically will not pay bounties that point out a patch gap between Firefox and a third party library we vendor, so long as the library has a history of being updated on a cadence.

All bounties paid will be at the discretion of the Mozilla Bounty Committee. The committee will evaluate the severity of reported issues with the help of engineers who work on the affected code. Security researchers are invited to participate in the assignment of ratings, but final decisions on the rating are at the discretion of the Bounty Committee.

Typically, the security rating given by the Bounty Committee for a bug must be rated a "sec-high" or "sec-critical" in order for it to be eligible for a bounty. In some circumstances, bounties may be paid for lower-rated bugs as well. (See Security Ratings for details of the rating qualifications.)

Rewards Amount

The bounty for a valid, potentially exploitable client security vulnerability rated critical or high is up to $20,000 (USD) cash, depending on the impact of the vulnerability and the quality of the report, as detailed below.

The bounty program encourages the earliest possible reporting of potentially exploitable bugs. A bounty is not determined based on the initial submission, 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 can increase your bounty payout.

Report Criteria

• A report should provide sufficient information to diagnose the vulnerability and produce a fix, and must include a simple, reproducible test case demonstrating the issue and at least one of the following:
• an ASAN stacktrace or crash dump (typically for memory trespassing/corruption)
• a root cause analysis of how the bug occurs or where the bug is located
• Notes:
• Bounties are not paid for issues which cannot be identified or fixed from the report.
• A bug that is limited in capability or affects a limited set of users will merit a lower payout. An example would be a sandbox escape that does not allow arbitrary code execution, but does allow arbitrary files to be read from the filesystem.
• Developing a full exploit is not required.
• 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.
• A report should not set severity keywords or include CVSS scores.

⁰A sandbox escape is defined as a method to run arbitrary attacker code with full user privileges in the parent process or natively on the user's computer. This can be achieved either through memory corruption or Javascript-based vulnerabilities. Vulnerabilities that assume arbitrary code execution in the content process - such as invoking an IPC method with attacker-controlled parameters - do qualify for Highest Impact.

¹ For Highest Impact, bypassing WebExtension Install Prompts excludes local attacks.

²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) will decrease the bounty award.

Exploit Mitigation Bug Bounty

Within Firefox, we have introduced vital security features, exploit mitigations, and defense in depth measures. If you are able to bypass one of these measures, even if you are operating from privileged access within the browser, you are eligible for a bounty.

Privileged access means bypassing the mitigation in a testing scenario; such as directly testing the HTML Sanitizer. However do note that as explained above in footnote ⁰, direct calls to an IPC method from a compromised content process is an expected attack vector and not considered a testing scenario; these are eligible for a Highest Impact bounty as well as the Bounty Bonus described below.

The mitigations we consider in scope for this bounty are:

• We compile certain libraries⁵ from C/C++ to wasm, isolating them in a memory-safe sandbox. To bypass the mitigation, you are allowed to introduce a memory corruption flaw into the library; after which point you would need to exploit the flaw to either achieve arbitrary code execution within the content process (or convince us it is possible via e.g. RIP control) or manipulate the library to provide output crossing the taint boundary (example) which causes Firefox to make an incorrect security-relevant decision.
• We use a Content Security Policy to prevent script execution in the Parent Process. A bypass would be either (a) a CSP bypass that would lead to a sandbox escape if there was a script injection vector (i.e. demonstrate there is a gap in the CSP even if you can't find a way to exploit that gap from the content process) or (b) a script injection vector that is only mitigated by the CSP (i.e. demonstrate a script injection vector from the content process that does not execute because of the CSP).
• We separate strings and ArrayBuffers into separate memory arenas from DOM Nodes. A bypass would be arbitrary control of memory layout in the same jemalloc arena as DOM nodes (i.e. full vtable overlayment).
• We sanitize HTML fragments before using them in privileged contexts. A bypass would be (i) finding a location we should be sanitizing (because it has attacker-controlled data) but aren’t or (ii) bypassing the HTML sanitizer with something that could execute JS³ in Firefox.
• We disallow eval() from being used in the System Principal context or the Parent Process. A bypass would be identifying a location where we still use eval that isn’t explicitly being allowed⁴, or how to abuse a location that is allowed.
• We apply a strong Content Security Policy to all internal about: pages, e.g. about:addons (and double-check we don't forget). A bypass would be identifying a way to run scripts or inject meaningful content bypassing the CSP of any about: page, excluding already-filed issues.
• We prevent anything except chrome://, resource:// and about: pages from loading in the parent process. A bypass would be showing a way an attacker-controlled page could be loaded, either by bypassing the checks in that function, or finding a place it is not correctly checked. We have an analogous check for preventing loads in the System Principal Context as well. (Note that Fission has recently caused refactoring to this function, but this mitigation is still in-scope with Fission disabled or enabled with (only) the fission.autostart pref.)
• We do not allow attacker-controlled JavaScript to run in the Parent Process - whether delivered from the internet or provided from a compromised content process. A bypass would be finding a way to execute javascript of your control in the parent process through any mechanism except PAC scripts.
• In Bugs 1479960, 1550900, and 1550037 we added support for sharing memory from the parent to child processes where the child process cannot modify the memory, but the parent can. A bypass would be finding a way to modify the memory from the child process.
• The Firefox UI is written in HTML/JavaScript, which means Firefox runs certain scripts with elevated privileges beyond what is ordinarily available to web content. To prevent privilege escalation attacks, Gecko implements a capability-based script security architecture (primarily implemented in js/xpconnect/wrappers), including special Xray Wrappers which prevent lesser-privileged JavaScript from confusing higher-privileged or differently-privileged Javascript when scripts interact across privilege boundaries. A bypass would be identifying a plausible exploitation scenario that occurs due to missing or incomplete sanitizing across compartments. A scenario is more likely to be considered “plausible” if it was the source of a past bug or is a code pattern we do elsewhere in-tree (the dependencies of bug 929539 show some examples which we previously worked to eliminate).
• We have a ReadOnlyPage implementation which is intended to prevent Data-Only attacks. A bypass would be reliably exploiting a race condition when the memory region is unprotected, finding a bug such that the memory region is left unprotected, or identifying a way around the mitigation to effect a data-only attack on the protected values.

³ Some styles are currently allowed by the sanitizer, but limited by the CSP to only allow chrome:// styles, which are part of the build. We will look at style-related issues on a case-by-case basis. We explicitly discourage researchers from re-styling a page for clickjacking attacks because we have a very high bar for an attack.

⁴ An example of such a bypass was identifying that we forgot to perform the checks on workers.

⁵ The selected lines may move, but we intended to link to the function wasm_sandboxing_libraries() which defines which libraries are wasmboxed.

Notes:

• Bypasses that involve obtaining a mis-issued Certificate Authority certificate will be decided on a case-by-case basis, but bypasses involving administrator-installed root certificates or CA-pinned connections will be ineligible.
• We believe all mitigations are present in the new Firefox Android app (previously Firefox for Android Preview - it’s the one with the URL bar at the bottom); therefore, that application is in-scope if the mitigation is present: the absence of a mitigation is something we would appreciate knowing about but may not be eligible on a bounty - it will be decided on a case-by-case basis. Our older Firefox for Android application (internal name “Fennec”) is excluded from this bounty.
• Other things may be considered a mitigation as well, but before assuming they would be, please confirm with us in #security or at security@mozilla.org

Bounty: Assuming the mitigation is bypassed in a testing scenario, with privileged access, we will treat a bypass of the above listed mitigations as High Impact using the table above.

Bounty Bonus: If the mitigation is bypassed without privileged access, this would count as both a regular security vulnerability eligible for a bounty and a mitigation bypass. The vulnerability payout will be decided per the criteria and table above and the mitigation bypass adds a bonus of an additional 50% of the payout for the category. For example, a UXSS vulnerability that bypasses our HTML sanitization would earn its UXSS payout of up to $10,000 plus an additional 50%.

Note: If you’re in the Bounty Bonus category, you may think submitting them separately could earn you slightly more money than submitting them together. We’re pretty sure that doing so would make the second report bounty-ineligible, but if you think each issue is fully independent, you’re welcome to submit them separately and we’ll consider it.

Claiming a Bug Bounty

To claim a bounty:

• Make sure you have a Bugzilla account.
• Use the bugzilla client bug bounty form to file the issue and automatically mark it for bug bounty consideration.
• In the "Description" field, please clearly describe one security issue. Please do not include extremely verbose output in the description field, and instead attach it as described below.
• If you have multiple bugs to file (for example, multiple findings from a single tool), file each one via this form individually, and we will link them as appropriate during review.
• Attach any supporting documents, such as "proofs of concept", reproduction cases, debug output or output from a tool. Again, use the "Attachment" option. While not required, such supporting documents will improve the quality of the submission and help us judge it more quickly and accurately. If you have multiple files to attach, it is better to attach one, submit the form, and then attach the remainder to the newly-created bug rather than attaching a zip file. (The exception is for a bundle of related files, like several log files, or test vector programs.)
• If you have filed the bug directly in Bugzilla without using the Bugzilla client bug bounty form, please immediately notify the Mozilla Security Group by email to security@mozilla.org and include the number of the bug you filed and a mention that you are submitting it for bounty consideration. Do not send the actual vulnerability via email.

We ask that you be available to follow along and provide further information on the bug as needed, and invite you to work together with Mozilla engineers in reproducing, diagnosing, and fixing the bug. As part of this process we will provide you full access to participate in our internal discussions about the bug; for more information read our policy for handling security bugs.