Chrome Reward Program Rules

The Chrome Reward Program was launched in January 2010 to help reward the contributions of
security researchers who invest their time and effort in helping us to make Chrome and
Chrome OS more secure. Through this program we provide monetary awards and public
recognition for vulnerabilities responsibly disclosed to the Chrome project.

Scope of program

Any security bug in Chrome or Chrome OS may be considered. It’s that
simple!*

* well, it's almost that simple. Two key points:

We are interested in bugs that make it to our Stable, Beta and Dev channels. We
discourage vulnerability hunting on canary or trunk builds, because they don't undergo
release testing and can exhibit short-lived regressions that are typically identified and
fixed very quickly.

We'd also love to learn about bugs in third-party components that we ship or use
(e.g. PDFium, Adobe Flash, Linux kernel). Bugs may be eligible even if they are part
of the base operating system and can manifest through Chrome.

Qualifying vulnerabilities

Only the first report of a given issue that we were previously unaware of is eligible.
In the event of a duplicate submission, the earliest filed bug report in the bug tracker is
considered the first report.

Bugs disclosed publicly or to a third-party for purposes other than fixing the bug will
typically not qualify for a reward. We encourage responsible disclosure, and
believe responsible disclosure is a two-way street; it's our duty to fix serious bugs
within a reasonable time frame.

If you have a fuzzer running as part of our Chrome Fuzzer Program, you will not receive
a reward if one of our fuzzers finds the same bug within 48 hours.

Reward amounts

Rewards for qualifying bugs typically range from $500 to $100,000.

We have a standing $100,000 reward for participants that can compromise a Chromebook or
Chromebox with device persistence in guest mode (i.e. guest to guest persistence with
interim reboot, delivered via a web page).

The following table outlines the usual rewards chosen for the most common classes of bugs:

High-quality report with
functional exploit [1]

High-quality report [2]

Baseline [3]

Low-quality report [4]

Sandbox Escape [5]

$15,000

$10,000

$2,000 - $5,000

$500

Renderer Remote Code Execution

$7,500

$5,000

$1,000 - $3,000

$500

Universal XSS (local bypass or equivalent)

$7,500

$5,000

N/A

N/A

Information Leak

$4,000

$2,000

$0 - $1000

$0

Download Protection bypass [6]

N/A

$1,000

$0 - $500

$0

[1] A high-quality report with a reliable exploit that demonstrates that the bug
reported can be easily, actively and reliably used against our users.[2] A report that includes a minimized test case and the versions of Chrome affected by
the bug. You will also demonstrate that exploitation of this vulnerability is very likely
(e.g. good control of EIP or another CPU register). Your report should be brief and well
written with only necessary detail and commentary.[3] A minimized test case or output from a fuzzer that highlights a security bug is
present without establishing that the issue is exploitable.[4] A report submitted with only a crash dump, without a Proof of Concept (PoC) or with
a poor quality PoC (e.g. a 1MB fuzz file dump with no attempt at reduction) that is later
verified to be a legitimate issue.[5] Escaping any layer of the sandbox (including the NaCl sandbox) will be considered as
a sandbox escape.[6] Landing a blacklisted test binary (malware example, UwS example) on disk where a typical
user could execute it, on Mac or Windows. The file type on disk must lead to non-sandboxed
code execution after minimal user interaction with the file. See the FAQ below for more
information.

The amounts listed are for good quality reports that don't require complex or
unlikely user interaction. Less convincing or more constrained bug submissions will
likely qualify for reduced reward amounts, as chosen at the discretion of the reward
panel.

Rewards apply to Chrome on Win 7+, MacOSX v10.9+, Linux, Android 4.4+, iOS 7+ and to
current versions of Chrome OS. We are also interested in bugs that affect Chrome on
Windows XP and Vista, which may qualify for a reduced reward amount.

On top of these rewards, we offer either $500 or $1,337 if a well-written patch is
provided with the report. The amount for this reward is determined by the panel based
on the quality and the effort required to write a good patch for the bug. Significant
patches can also be submitted under our Patch Reward
Program.

The final amount is always chosen at the discretion of the reward panel. In particular, we
may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide
that a single report actually constitutes multiple bugs; or that multiple reports are so
closely related that they only warrant a single reward.

We understand that some of you are not interested in money. We offer the option to donate
your reward to an established charity. If you do so, we will double your donation - subject
to our discretion. Any rewards that are unclaimed after 12 months will be donated to a
charity of our choosing.

Investigating and reporting bugs

All bugs should be reported via this
form. Note that your submission is over HTTPS and does not require additional
encryption. Bugs that are found in Google's server-side services should be reported under
the Google Vulnerability Rewards Program
instead.

When investigating a vulnerability, please, only ever target your own computers. Never
attempt to access anyone else's data and do not engage in any activity that would be
disruptive or damaging to your fellow users or to Google.

Note that we are only able to answer to technical vulnerability reports. Non-security bugs
and queries about problems with your account should be instead directed to Google Help Centers.

Chrome Fuzzer Program

The Chrome Fuzzer Program allows you to run fuzzers on Google hardware at Google scale
across thousands of cores. You receive 100% of the reward value for any bugs found by your
fuzzer plus a bonus $500, provided the same bug was not found by one of our fuzzers within
48 hours. There are two ways to participate:

libFuzzer

LibFuzzer
allows fuzz testing of individual components in the Chrome browser, and are just as easy to
write as unit tests. Any Chromium contributor can submit libFuzzer tests to the Chromium
codebase, which will be picked up and run at scale by our fuzzing automation system,
ClusterFuzz.

ClusterFuzz

Fuzzers can also be written to use
ClusterFuzz directly. This allows fuzzers to be written in a wide range of languages
and to take advantage of ClusterFuzz's more advanced options. Previously this was only
available to members of the Trusted Researcher Program but is now open to all.

Before being submitted, fuzzers using either method must:

Test features shipping in production code that are susceptible to malicious user input.

Have found at least one vulnerability in local testing and reported in Chromium
tracker.

Frequently asked questions

Q: How can I maximize the potential reward for my report?

A: Our lowest reward for eligible bugs is $500. If the rewards panel finds the bug
particularly severe, the value can be higher than what is listed above in the table. To
date, we've given out several instances of rewards $30,000 and higher. To improve your
chances, please adhere to the guidelines provided in Reporting
Security Bugs.

Q: How do I find out if my bug is eligible?

A: You will see a provisional comment to that effect in the bug entry once we have triaged
the bug or the "reward-topanel" label on your bug.

Q: What happens if I disclose the bug publicly before you had a chance to fix it?

A: Please read our stance on
coordinated disclosure. In essence, our pledge to you is to respond promptly and fix
bugs in a sensible timeframe - and in exchange, we ask for a reasonable advance notice.
Reports that go against this principle will usually not qualify, but we will evaluate them
on a case-by-case basis.

Q: I wish to report an issue through a vulnerability broker / someone not you. Will my
report still qualify for a reward?

A: We believe that it is against the spirit of the program to privately disclose the flaw
to third parties for purposes other than actually fixing the bug. Consequently, such
reports will typically not qualify.

Q: What if somebody else also found the same bug?

A: Only the first report of a given issue that we were previously unaware of is eligible.
In the event of a duplicate submission, the earliest filed bug report in the bug tracker is
considered the first report.

Q: What about bugs present in Google Chrome but not the Chromium open source
project?

A: Bugs in either build may be eligible. In addition, bugs in plug-ins that are shipped
with Google Chrome by default (e.g. PDFium, Adobe Flash) are usually eligible. Bugs in
third-party plug-ins and extensions are ineligible.

Q: Do I still qualify if I disclose the problem publicly once fixed?

A: Yes, absolutely. We encourage open collaboration. We will also make sure to credit you
in the relevant Google Chrome release notes and the rewards Hall of Fame.

Q: What about bugs in channels other than Stable?

A: We are interested in bugs in the Stable, Beta and Dev channels because it's best for
everyone to find and fix bugs before they are released to the Stable channel. However, we
discourage testing against canary or trunk builds, because they don't undergo release
testing and can exhibit short-lived regressions that are typically identified and fixed
very quickly.

Q: What about bugs in third-party components?

A: These bugs are often eligible (e.g. libxml, image libraries, compression libraries,
etc). As long as they can manifest through or affect Chrome, bugs may be eligible even if
they are caused by components of the operating system or standard libraries. We're
interested in rewarding any information that enables us to better protect our users. In the
event of bugs in an external component, we are happy to take care of responsibly notifying
other affected parties.

Q: Can you keep my identity confidential from the rest of the world?

A: Yes. If selected as the recipient of a reward, and you accept, we will need your contact
details in order to pay you. However, at your discretion and if you ask us before the bug
is made public, we can credit the bug to "anonymous" and remove identifying information
from the bug entry.

Q: Can I submit my report now and provide a working exploit later? Is there a time
limit for submitting an exploit?

A: Most definitely! We encourage this approach as it allows us to work on fixing the bug as
soon as possible. It also minimizes the chance that someone else reports the same issue
while you're working up an exploit. Although we don't have a set time limit, we would
expect that the exploit would follow within a few weeks of the initial report. Exploits
submitted outside of this time frame are unlikely to be rewarded.

Q: What is the Trusted Researcher program? Can you run my fuzzer for me?

The easiest way to get an invite into this program is to submit quality bugs that are found
with one of your fuzzers. If we like what we see, we’ll reach out with the details!

Q: Why are these rewards significantly less than the old Pwnium?

A: The prizes at Pwnium were large (up to $150,000) because Pwnium has significant
restrictions as a competition. Former Pwniums required a physical presence at the
competition location, a successful demonstration of your exploit on a future version of
Chrome and the delivery of a full-chain exploit via a webpage - all while doing this on one
of our latest Chromebooks in a short time window in March!

Even if you had a bug that met all of these criteria, you still ran the risk of Google
fixing the bug before Pwnium or someone else reporting the issue to us if you chose to wait
for the competition. As we build a more secure browser, we believe that Pwnium-style
bug-chains will be significantly harder to come by, as evidenced by the handful of people
who entered that competition.

Q: What about full-chain exploits on platforms other than Chrome OS?

A: We are interested in full-chain exploits against Chrome running on other platforms. For
example and referring to the table above, a high-quality full-chain exploit that escapes
the sandbox on non-Chrome OS platforms would likely receive at least $22,500 ($15,000 for
the sandbox escape portion, $7,500 for the code execution in the renderer). In addition,
any other bugs in the operating system that can manifest through Chrome are highly likely
to be rewarded as well.

Q: Can I have more details about the Download Protection bypass rewards?

A: Sure! Here are all of the qualifying rules you need to consider:

Safe Browsing must be enabled on Chrome and have an up-to-date database (this may take
up to a few hours after a new Chrome install).

Safe Browsing servers must be reachable on the network.

Binary must land in a location a user is likely to execute it (e.g. Downloads folder).

The user can’t be asked to change the file extension or recover it from the blocked
download list.

Any gestures required must be likely and reasonable for most users. As a guide,
execution with more than three reasonable user gestures (eg: click to download, open .zip,
launch .exe) is unlikely to qualify, but it’ll be judged on a case-by-case basis. The user
can’t be expected to bypass warnings.

The download should not send a Download Protection Ping back to Safe Browsing. Download
Protection Pings can be measured by checking increments to counters at
chrome://histograms/SBClientDownload.CheckDownloadStats. If a counter increments, a check
was successfully sent (with exception to counter #7, which counts checks that were not
sent).

The binary’s hosting domain and any signature can not be on a whitelist. You can
measure this by checking chrome://histograms/SBClientDownload.SignedOrWhitelistedDownload
does not increment.

Q: Will Google reward for bugs that are not specifically listed in the table
above?

A: Yes - we're interested in rewarding any information that enables us to better protect
our users. All of our reward amounts are based on the quality of the report and the
security impact of the bug.

Q: The black market / my friend Ned pays more for my bugs! Do these comparatively low
reward levels encourage the sale of bugs to people in trenchcoats and dark sunglasses?

A: We understand that there are dark corners of the Internet that may pay you more money to
purchase any vulnerabilities that you find or exploits that you develop. These people buy
vulnerabilities and exploits for offensive purposes to target other users on the Internet.
We believe that the reward you are getting comes with strings attached - including buying
your silence and accepting that any bug you sell may be used to target other people without
their knowledge. We understand that our cash reward amounts can be less than these
alternatives, but we offer you public acknowledgement of your skills and how awesome you
are, a quick fix and an opportunity to openly blog/talk/present on your amazing work (while
still offering you a very healthy financial reward for your work!). Also, you'll *never*
have to be concerned that your bugs were used by shady people for unknown purposes.

Legal points

We are unable to issue rewards to individuals who are on sanctions lists, or who are in
countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. 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.

This is not a competition, but rather an experimental and discretionary rewards program.
You should understand that we can cancel the program at any time and the decision as to
whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is
not your own.