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: In addition to our general eligibility requirements, submissions must be either an static analysis submission, exploit mitigation bypass or a security bug demonstrating the ability to perform an unauthorized action or obtain access to otherwise-restricted information.

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.

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 valid potentially exploitable critical and high security rated client security vulnerabilities will be between $20,000 and $3,000 (USD) cash reward, 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 will increase your bounty payout.

Baseline Report

• Sufficient information to diagnose the vulnerability and produce a fix. Examples:
• ASAN Stacktrace or Crash Dump (typically for Memory Trespassing/Corruption)
• Trigger point (for UXSS)
• ASAN Nightly bug reports
• Notes:
• 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 72-hour collision window), exceptions are made for reports that are not actionable and require additional information provided by another party.

High Quality Report

• Includes at least two of the following:
• (for memory corruption) demonstrated control over the PC or memory read/write location, with documentation for how it is achieved
• a root cause analysis of where the bug is located
• a proof of concept that reproduces the vulnerability, easily integrated into our test suite
• Submissions that include some aspects of a high quality report will qualify for a bounty between the minimum and maximum.
• Notes:
• A bug that is limited in capability may meet all the criteria for a High Quality report, but will merit a lower payout because of its limited capability. 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 for a High Quality Report.
• The intent of the proof of concept is to enable us to create a test that we can integrate into our test coverage. We encourage you to submit the bug immediately, and if you wish to meet this criteria, ask what will qualify. For assertion/crash-based tests it is usually sufficient to provide a minimal reproducing html or js file. For more complicated bugs, we would ask you to develop the POC into an actual test (e.g. gtest, xpcshell, mochitest) which we can provide some mentorship for.

⁰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 only being able to inject into a cross-origin domain, but not an arbitrary cross-origin domain) may decrease the bounty award.

³ If precise control of the OOM condition can be demonstrated, this will be considered High Impact.

⁴ Denial of Service issues that merely crash the browser are not eligible for a bounty.

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 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, with the same payout range for baseline to high quality report.

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 baseline payout for the category. e.g. a UXSS vulnerability that bypasses our HTML sanitization would earn $18K - $20K plus an additional $9000.

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.

Static Analysis Bounty

We also have a program that rewards the submission of static analysis tools that identify present or historical security vulnerabilities in Firefox. We will accept static analysis queries written as clang-based checkers - we have some documentation that may help you get started or integrate and run over Firefox as a whole. Submissions should be made following our instructions below.

We will issue a bounty for the query itself, dependent upon the quality of the submission. Because this is an experiment, we are not committing to an exact amount or range for the bounty, but we expect this will typically be in the $2500-$7500 range.

Additionally, if your query matches presently unknown security vulnerabilities, each vulnerability it matches will be considered for a bounty independently. The amount awarded is dependent on the submission quality, as per normal bounty policy. For example purposes, we’ll assume a high or critical vulnerability (which is the most common case for memory corruption.) A report that only shows the output of the tool would be at the minimum end ($3000), and may be less if you submit multiple false positives we need to spend time validating. However a report that includes documentation explaining and validating that the issue is in fact a vulnerability would be eligible for an increased payout. A submission that includes documentation and a test case (which we acknowledge may be difficult for bugs found via this method) would be eligible for the maximum end ($5000).

The quality of the static analysis submission will be judged on:

• Complexity of the query. Is the query identifying a simplistic or syntactical issue with tight locality? Or is it identifying a semantic problem across complicated data flows?
• Documentation of the query. How does it work, and how did you develop it. What things did you try that didn’t work, and how did you refine it. Crucially: when trying to find the bad pattern, what edge cases does your query miss?
• Test vectors. Can you supply simple C++ programs that illustrate the vulnerable code patterns that the query matches. Can you supply programs that are edge cases the query misses?
  • While it may seem unusual to highlight shortcomings of your submission, from our perspective this makes the submission stronger - it gives us confidence you tested it in multiple scenarios, and shows us how we may be able to improve it.
• What Firefox issues does it identify, either currently unknown, or previously known and fixed? This is your opportunity to argue the usefulness of your query: we’re not going to run your query on historical versions of the codebase, so you should and demonstrate the bugs the query identifies. The more you can identify, the stronger your case is. As a rule of thumb, a query that identifies less than three distinct issues will need an exceptionally strong argument for its future usefulness.
• The false positive rate of the query. As a rule of thumb, a query should have fewer false positives than true positives. Which means if it matches 1 valid historical issue and 3 current, false positives - you should seek to identify additional historical issues it matches or refine the query.
• Uniqueness of the query. If we receive multiple query submissions that do the same thing, we will consider the first reported. This is similar to our existing policy that the issue must be previously unreported. However, if your submission improves upon a prior submitted query, we will consider a (smaller) bounty for your improvement upon the prior query.

More about "Complexity of the query": Consider a function that returns -1 for error, 0 for failure, and 1 for success. Miscasting this return value into a boolean is a common mistake, and we surely have some historical instances of this in our code base. If you identify a function that still has this (bad) API, such a simplistic syntactical query is still valuable to us. If the API is ours, we should fix the API and if the API isn’t ours, we should use static analysis to prevent such a flaw from occurring. But it’s not a very sophisticated query. On the flip side, a query that does data flow analysis between a user-controlled source and attacker-controlled sink, accounting for complex transitions along the way (like IPC or JS/C++ boundaries) - that is a very sophisticated query.

Examples of Quality of Submission: As mentioned, the bounty amount we grant for the query will be determined based on the quality of the submission, and an estimation of the number of issues we think it may identify in a one to three-year timespan. On the low end, if you submit a query that identifies a single historical issue of a syntactical misuse of an API we are unlikely to use in future code, we may not issue a bounty, and if we did it would be below the $2500 range. And on the high end, if you submit a query that matches 3 unknown issues today, in code written in the last year - we can expect it will identify a significant number of issues in the future and would be looking above the $7500 range. (Plus you’d be eligible for separate bounties on those 3 issues.)

Note: While we previously accepted submissions of CodeQL queries, we no longer do. You are of course encouraged to develop CodeQL queries if you think they will be valuable, and submit any findings you glean from them.

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 or static analysis submission. 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.
• If submitting a static analysis submission, use the "Attachment" option to attach the source code of the query or plugin.
• 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.