Android Security Rewards Program Rules

The Android Security Rewards program recognizes the contributions of security researchers
who invest their time and effort in helping us make Android more secure. Through this
program we provide monetary rewards and public
recognition for vulnerabilities disclosed to the Android Security Team. The reward
level is based on the bug severity and increases for complete reports that include
reproduction code, test cases, and patches.

Scope of program

This program covers security vulnerabilities discovered in the latest available Android
versions for Pixel phones and tablets. This set of devices will change over time, but as of
October 2017 this covers:

Android Security Rewards covers bugs in code that runs on eligible devices and isn't
already covered by other reward programs at Google. Eligible bugs include those in AOSP
code, OEM code (libraries and drivers), the kernel, and the TrustZone OS and modules.
Vulnerabilities in other non-Android code, such as the code that runs in chipset firmware,
may be eligible if they impact the security of the Android OS.

Non-AOSP apps developed by Google and published in Google Play may be covered under our
Google VRP, which
also covers server-side issues. Vulnerabilities in Chrome may be handled under the Chrome Rewards program.

At this time, vulnerabilities that only affect other Google devices (such as Nexus Player,
Android Wear, or Project Tango) are not eligible for Android Security Rewards.

There are a few rules that we follow when rewarding a vulnerability report:

Only the first report of a specific vulnerability will be rewarded.

A bug report must include as much detail as possible, a buildable proof of concept,
crash dump if available, and any additional repro steps. For tips on how to submit complete
reports, refer to
Bug Hunter University.

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

There are also a few classes of vulnerabilities that will generally not qualify for a
reward:

Issues that require complex user interaction. For example, if the vulnerability
requires installing an app and then waiting for a user to make an unlikely configuration
change.

Phishing attacks that involve tricking the user into entering credentials.

Tap-jacking and UI-redressing attacks that involve tricking the user into tapping a UI
element.

Issues that only affect userdebug builds or require debugging access (ADB) to the
device.

Bugs that simply cause an app to crash.

Low severity issues typically do not qualify for rewards, as described in Bug Hunter
University, with some exceptions.

Reward amounts

The reward amount depends on the severity of the vulnerability and the quality of the
report. A valid but low quality bug report may receive up to $200. A complete report
includes as much detail as possible, a proof of concept, crash dump if available, and any
additional repro steps. The proof of concept should be standalone reproduction code or a
malformed file that reproduces the issue. Malformed files that are copyright material or
can’t be distributed with a CTS test may qualify for a lower reward amount.

This table shows the reward amounts for typical rewards, effective June 1, 2017. (Any
submissions prior to June 1 will be paid using the previous rewards table):

Severity

Complete Report* + PoC

Payment range (if report includes an exploit leading to Kernel compromise)**

Payment range (if report includes an exploit leading to TEE compromise)**

Critical

Required

Up to $150,000

Up to $200,000

High

Required

Up to $75,000

Up to $100,000

Moderate

Required

Up to $20,000

Up to $35,000

Low

Required

Up to $330

Up to $330

* Bug reports that are incomplete or do not include a proof of concept will receive up to
$200 depending on severity.

** Subject to the discretion of the rewards committee

Patch and CTS tests submissions may qualify for a reward up to $1000 each. The final amount
will be paid as per the discretion of rewards committee. Submitted CTS tests and patches
must apply cleanly to AOSP's master branch, comply with Coding Style Guidelines, and be
accepted as the actual fix to be eligible for these additional reward amounts.

Researchers submitting reports including a proof of concept via Android security rewards
program for reports originally submitted to third party bug bounty programs may qualify for
a $1000 bonus reward, where we do not already have a working proof of concept. To qualify
for this bonus reward, researchers are required to provide the CVE ID of the issue having
been addressed in an Android Security Bulletin on an eligible device.

The final amount is always chosen at the discretion of the reward panel. In particular, we
may decide to pay even more 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 using the Android Security Issue template. If you
are submitting a patch or CTS test, please attach the files to the bug report. Again, if
your patch or test doesn’t conform to Android's Coding Style Guidelines, we may
reduce the reward amount.

When investigating a vulnerability, please, only ever target your own devices. 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.

Frequently asked questions

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

A: To earn as much money as possible for your bug, include a high quality bug report, a
proof of concept, a patch, and a CTS test. Ensure that your patch and CTS test adhere to
Android's Code Style
Guidelines; we may lower the reward amount if the code requires a lot of fixing up
before we can include it in the Android source tree.

Q: Can I still receive a reward even if I don’t submit a full working exploit?

A: Yes! Our program rewards issues that contain a complete report and a working proof of
concept, even if a full working exploit is not provided. As reported in our blog,
during the most recent full year of our rewards program, our average payout for these
categories of issues was over $2000 per issue and $10,000 per researcher in our program.
The exact payout amounts will be at the discretion of the awards committee, based on the
severity of the issue and the completeness of the report.

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

A: We'll let you know if your bug may be eligible, and we'll let you know once the panel
decides on a reward amount. We can't tell you if your bug will qualify before you give us
the details.

Q: If the bug is classified as low, when will it be fixed and will a CVE ID be assigned
?

A:Low severity issues are generally addressed in the next major versions, instead of
through our Monthly Security Bulletins, and we will generally not assign CVEs for this
severity level.

Q: What happens if I disclose the bug publicly before a fix is available?

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.Note that we will pay rewards out before the bug has been fixed in many
cases. If you disclose the bug after getting the reward but without giving us a reasonable
deadline for fixing the issue, you may not be eligible for future rewards.

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 that are only present in other popular, non-Nexus devices?

A: If a bug does not affect the latest version of Android available on an eligible device
currently for sale in the U.S. in the Google Store, it will not qualify for a reward.

Q: What about bugs in custom ROMs for eligible Nexus devices?

A: No, bugs in custom ROMS are not covered.

Q: What if a bug has already been reported but still affects the latest Android version
available on a device currently for sale in the Google Store?

A: We would still request that you submit the report. We are likely only be able to reward
the first person who reports a bug to us, but will determine that on a case by case basis.

Q: For the purpose of exploit rewards, what is a "remote or proximal" attack
vector?

A: A remote attack vector means that the exploit could be launched against a target without
regard for the device's physical location. For example, the exploit could be triggered by
visiting a web page, by opening an email, or receiving an SMS/MMS message. Proximal means
that the exploit must be launched in close physical proximity to the device. For example,
an attack involving a bug in the WiFi, radio, or Bluetooth stacks require being physically
proximal to the target device.

We consider attacks against NFC and USB to be a physical attack vector and exploits are
rewarded the same as if the exploit was launched from an app.

Q: For the purpose of exploit rewards, what is a "kernel compromise"?

A: We mean that the integrity of the kernel has been breached. This could be achieved with
arbitrary code execution in the kernel or with arbitrary kernel writes — for example, to
disable SELinux.

Q: What about bugs in third-party components?

A: These bugs are often eligible (e.g., image libraries, media libraries, compression
libraries, etc.). Note that we assign the severity rating based on the impact to Android.
Only bugs that can be manifest or exploited through Android will be eligible.

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 patch and 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: When submitting a bug, please include steps to reproduce the issue and a working proof
of concept to maximize your reward. We are willing to accept a fully working exploit a few
weeks after the initial report. Exploits submitted outside of this time frame are unlikely
to be rewarded.

Legal points

We are unable to issue rewards to individuals who are on sanctions lists, or who are in
countries (e.g. Crimea, 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.

To avoid potential conflicts of interest, we will not grant rewards to people employed by
Google or Google Partner companies who develop code for devices covered by this program.