As part of our continuous commitment to improve the security of the Android ecosystem, we are partnering with Arm to design the memory tagging extension (MTE). Memory safety bugs, common in C and C++, remain one of the largest vulnerabilities in the Android platform and although there have been previous hardening efforts, memory safety bugs comprised more than half of the high priority security bugs in Android 9. Additionally, memory safety bugs manifest as hard to diagnose reliability problems, including sporadic crashes or silent data corruption. This reduces user satisfaction and increases the cost of software development. Software testing tools, such as ASAN and HWASAN help, but their applicability on current hardware is limited due to noticeable overheads.
MTE, a hardware feature, aims to further mitigate these memory safety bugs by enabling us to detect them with low overhead. It has two execution modes:
Arm recently published a whitepaper on MTE and has added documentation to the Arm v8.5 Architecture Reference Manual.
We envision several different usage modes for MTE.
We believe that memory tagging will detect the most common classes of memory safety bugs in the wild, helping vendors identify and fix them, discouraging malicious actors from exploiting them. During the past year, our team has been working to ensure readiness of the Android platform and application software for MTE. We have deployed HWASAN, a software implementation of the memory tagging concept, to test our entire platform and a few select apps. This deployment has uncovered close to 100 memory safety bugs. The majority of these bugs were detected on HWASAN enabled phones in everyday use. MTE will greatly improve upon this in terms of overhead, ease of deployment, and scale. In parallel, we have been working on supporting MTE in the LLVM compiler toolchain and in the Linux kernel. The Android platform support for MTE will be complete by the time of silicon availability.
Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem. Based on the current data points, MTE provides tremendous benefits at acceptable performance costs. We are considering MTE as a possible foundational requirement for certain tiers of Android devices.
Thank you to Mitch Phillips, Evgenii Stepanov, Vlad Tsyrklevich, Mark Brand, and Serban Constantinescu for their contributions to this post.
TL;DR We increased the Chrome Fuzzer Program bonus from $500 to $1,000 as part of our recent update of reward amounts.
Chrome Fuzzer Program is a part of the Google Chrome Vulnerability Reward Program that lets security researchers run their fuzzers at scale on the ClusterFuzz infrastructure. It makes bug reporting fully automated, and the fuzzer authors get the same rewards as if they reported the bugs manually, plus an extra bonus ($1,000 as of now) on top of it for every new vulnerability.
We run fuzzers indefinitely, and some of the fuzzers contributed years ago are still finding security issues in ever changing Chrome code. This is a win-win for both sides, as security researchers do not have to spend time analyzing the crashes, and Chrome developers receive high quality bug reports automatically.
To learn more about the Chrome Fuzzer Program, let’s talk to Ned Williamson, who’s been a participant since 2017 and now works on the Google Security team.
Q: Hey Ned! It looks like you’ve received over $50,000 by participating in the Google Chrome Vulnerability Reward Program with your quic_stream_factory_fuzzer.
A: Yes, it’s true. I wrote a fuzzer for QUIC which helped me find and report two critical vulnerabilities, each worth $10,000. Because I knew my fuzzer worked well, I submitted it to the Chrome Fuzzer Program. Then, in the next few months, I received that reward three more times (plus a bonus), as the fuzzer caught several security regressions on ClusterFuzz soon after they happened.
Q: Have you intentionally focused on the areas that yield higher severity issues and bigger rewards?
A: Yes. While vulnerabilities in code that is more critical to user security yield larger reward amounts, I actually started by looking at lower severity bugs and incrementally began looking for more severe bugs until I could find critical ones. You can see this progression by looking at the bugs I reported manually as an external researcher.
Q: Would you suggest starting by looking for non-critical bugs?
A: I would say so. Security-critical code is generally better designed and more thoroughly audited, so it might be discouraging to start from there. Finding less critical security bugs and winning bounties is a good way to build confidence and stay motivated.
Q: Can you share an algorithm on how to find security bugs in Chrome?
A: Looking at previous and existing bug reports, even for non-security crashes, is a great way to tell which code is security-critical and potentially buggy. From there, if some code looks like it’s exposed to user inputs, I’d set up a fuzzing campaign against that component. After you gain experience you will not need to rely on existing reports to find new attack surface, which in turn helps you find places that have not been considered by previous researchers. This was the case for my QUIC fuzzer.
Q: How did you learn to write fuzzers?
A: I didn’t have any special knowledge about fuzzing before I started looking for vulnerabilities in Chrome. I followed the documentation in the repository and I still follow the same process today.
Q: Your fuzzer isn’t very simple compared to many other fuzzers. How did you get to that implementation?
A: The key insight in the QUIC fuzzer was realizing that the parts of the code that handled plaintext messages after decryption were prone to memory corruption. Typically, fuzzing does not perform well with encrypted inputs (it’s pretty hard to “randomly” generate a packet that can be successfully decrypted), so I extended the QUIC testing code to allow for testing with encryption disabled.
Q: Are there any other good examples of fuzz targets employing a similar logic?
A: Another example is pdf_formcalc_context_fuzzer that wraps the fuzzing input around with a valid hardcoded PDF file, therefore focusing fuzzing only on the XFA script part of it. As a researcher, you just need to choose what exactly you want to fuzz, and then understand how to execute that code properly. Looking at the unit tests is usually the easiest way to get such an understanding.
Useful links:
Happy fuzzing and bug hunting!
Chrome has always been built with security at its core, by a passionate worldwide community as part of the Chromium open source project. We're proud that community includes world class security researchers who help defend Chrome, and other Chromium based browsers.
Back in 2010 we created the Chrome Vulnerability Rewards Program which provides cash rewards to researchers for finding and reporting security bugs that help keep our users safe. Since its inception the program has received over 8,500 reports and paid out over five million dollars! A big thank you to every one of the researchers - it's an honor working with you.
Over the years we've expanded the program, including rewarding full chain exploits on Chrome OS, and the Chrome Fuzzer Program, where we run researchers' fuzzers on thousands of Google cores and automatically submit bugs they find for reward.
Today, we're delighted to announce an across the board increase in our reward amounts! Full details can be found on our program rules page but highlights include tripling the maximum baseline reward amount from $5,000 to $15,000 and doubling the maximum reward amount for high quality reports from $15,000 to $30,000. The additional bonus given to bugs found by fuzzers running under Chrome Fuzzer Program is also doubling to $1,000.
We've also clarified what we consider a high quality report, to help reporters get the highest possible reward, and we've updated the bug categories to better reflect the types of bugs that are reported and that we are most interested in.
But that's not all! On Chrome OS we're increasing our standing reward to $150,000 for exploit chains that can compromise a Chromebook or Chromebox with persistence in guest mode. Security bug in firmware and lock screen bypasses also get their own reward categories.
These new reward amounts will apply to bugs submitted after today on the Chromium bug tracker using the Security template. As always, see the Chrome Vulnerability Reward Program Rules for full details about the program.
In other news, our friends over at the Google Play Security Reward Program have increased their rewards for remote code execution bugs from $5,000 to $20,000, theft of insecure private data from $1,000 to $3,000, and access to protected app components from $1,000 to $3,000. The Google Play Security Reward Program also pays bonus rewards for responsibly disclosing vulnerabilities to participating app developers. Check out the program to learn more and see which apps are in scope.
Happy bug hunting!
Follow