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 a static analysis submission 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 and 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 current main development or released versions of Firefox or Firefox for Android as released by Mozilla Corporation (e.g. Nightly mozilla-central or Beta test versions, as well as the final release product versions).
- The security rating given by the Bounty Committee for a bug must be rated a "sec-critical" or a "sec-high" in order for it to be eligible for a bounty. Some "sec-moderate" bugs may be eligible for the bounty as well. (See Security Ratings for details of the rating qualifications.)
- 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.
- Submissions should be made following our instructions below.
The bounty for valid potentially exploitable critical and high security rated client security vulnerabilities will be between $3000 and $7500 (USD) cash reward. The bounty program encourages the earliest possible reporting of these potentially exploitable bugs. A bounty may be paid for some moderate rated client security bugs at the discretion of the Bug Bounty Committee. If a bounty is paid for a moderate rated security issue, the amount will be between $500 and $2000 (US), depending on the severity of impact for the issue as determined by Bug Bounty Committee.
Here are some examples how to receive a higher reward
- The researcher can demonstrate new classes of attacks, or techniques for bypassing security features
- Or, if an existing vulnerability can be demonstrated to be exploitable though additional research by the reporter, additional compensation can be earned for the same bug. Research might also uncover extremely severe, complex, or interesting problem areas that were previously unreported or unknown issues. Examples of severe or complex bugs would be: Use After Free bugs that also allow for ASLR bypass; bypassing the Firefox security wrappers to allow content to manipulate browser components, or a vulnerability that allows you to break out of a sandboxed process.
- You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.
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.
|Novel vulnerability and exploit, new form of exploitation or an exceptional vulnerability||High quality bug report with clearly exploitable critical vulnerability1||High quality bug report of a critical or high vulnerability2||Typical minimum for a high or critical vulnerability3||Medium vulnerability|
|$10,000+||$7,500||$5,000||$3,000||$500 - $2500|
1This is a report that includes details on exploitation of the vulnerability. A good example of this is a vulnerability that can gain remote code execution without the need of another vulnerability.
2This is a high quality report that includes minimized test cases and clear stack traces.
3 This is a bug that includes a fuzzer report or a crash dump.
Static Analysis Bounty
In coordination with the GitHub Security Lab, we have launched a new 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 in CodeQL or as clang-based checkers (clang analyzer, clang plugin using the AST API or clang-tidy). 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.)
Compatibility with Github’s Bounty: Github’s bounty policy is compatible with Mozilla’s. This means that if you follow both Mozilla’s and Github’s policies, you are eligible to earn a bounty from both. Note that this includes not providing unfixed vulnerabilities or queries that identify unfixed vulnerabilities in Mozilla products to third parties (i.e. Github). Once we’ve resolved the issues, they have a CVE issued, and our MFSA has become public, then you can submit to Github. Please, please talk to us if you have questions about this before sharing potentially confidential information.
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 email@example.com 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.