Google Online Security Blog

Expanding bug bounties on Google Play

29 اگست، 2019

Posted by Adam Bacchus, Sebastian Porst, and Patrick Mutchler — Android Security & Privacy [Cross-posted from the Android Developers Blog]

We’re constantly looking for ways to further improve the security and privacy of our products, and the ecosystems they support. At Google, we understand the strength of open platforms and ecosystems, and that the best ideas don’t always come from within. It is for this reason that we offer a broad range of vulnerability reward programs, encouraging the community to help us improve security for everyone. Today, we’re expanding on those efforts with some big changes to Google Play Security Reward Program (GPSRP), as well as the launch of the new Developer Data Protection Reward Program (DDPRP). Google Play Security Reward Program Scope Increases We are increasing the scope of GPSRP to include all apps in Google Play with 100 million or more installs. These apps are now eligible for rewards, even if the app developers don’t have their own vulnerability disclosure or bug bounty program. In these scenarios, Google helps responsibly disclose identified vulnerabilities to the affected app developer. This opens the door for security researchers to help hundreds of organizations identify and fix vulnerabilities in their apps. If the developers already have their own programs, researchers can collect rewards directly from them on top of the rewards from Google. We encourage app developers to start their own vulnerability disclosure or bug bounty program to work directly with the security researcher community. Vulnerability data from GPSRP helps Google create automated checks that scan all apps available in Google Play for similar vulnerabilities. Affected app developers are notified through the Play Console as part of the App Security Improvement (ASI) program, which provides information on the vulnerability and how to fix it. Over its lifetime, ASI has helped more than 300,000 developers fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users until the issue is fixed. To date, GPSRP has paid out over $265,000 in bounties. Recent scope and reward increases have resulted in $75,500 in rewards across July & August alone. With these changes, we anticipate even further engagement from the security research community to bolster the success of the program. Introducing the Developer Data Protection Reward Program Today, we are also launching the Developer Data Protection Reward Program. DDPRP is a bounty program, in collaboration with HackerOne, meant to identify and mitigate data abuse issues in Android apps, OAuth projects, and Chrome extensions. It recognizes the contributions of individuals who help report apps that are violating Google Play, Google API, or Google Chrome Web Store Extensions program policies. The program aims to reward anyone who can provide verifiably and unambiguous evidence of data abuse, in a similar model as Google’s other vulnerability reward programs. In particular, the program aims to identify situations where user data is being used or sold unexpectedly, or repurposed in an illegitimate way without user consent. If data abuse is identified related to an app or Chrome extension, that app or extension will accordingly be removed from Google Play or Google Chrome Web Store. In the case of an app developer abusing access to Gmail restricted scopes, their API access will be removed. While no reward table or maximum reward is listed at this time, depending on impact, a single report could net as large as a $50,000 bounty. As 2019 continues, we look forward to seeing what researchers find next. Thank you to the entire community for contributing to keeping our platforms and ecosystems safe. Happy bug hunting!

Protecting Chrome users in Kazakhstan

21 اگست، 2019

Posted by Andrew Whalley, Chrome Securityrecent actionsalong with other browsers

Common Name	Qaznet Trust Network
SHA-256 Fingerprint	00:30:9C:73:6D:D6:61:DA:6F:1E:B2:41:73:AA:84:99:44:C1:68:A4:3A:15: BF:FD:19:2E:EC:FD:B6:F8:DB:D2
SHA-256 of Subject Public Key Info	B5:BA:8D:D7:F8:95:64:C2:88:9D:3D:64:53:C8:49:98:C7:78:24:91:9B:64: EA:08:35:AA:62:98:65:91:BE:50

CRLSethas been added

How Google adopted BeyondCorp: Part 2 (devices)

20 اگست، 2019

Posted by Matt McDonald, Software Engineer, and Sebastian Harl, Software Engineer

Intro
This is the second post in a series of four, in which we set out to revisit various BeyondCorp topics and share lessons that were learnt along the internal implementation path at Google.

The first post in this series focused on providing necessary context for how Google adopted BeyondCorp. This post will focus on managing devices - how we decide whether or not a device should be trusted and why that distinction is necessary. Device management provides both the data and guarantees required for making access decisions by securing the endpoints and providing additional context about it.
How do we manage devices?
At Google, we use the following principles to run our device fleet securely and at scale:

Secure default settings at depth with central enforcement

Ensure a scalable process

Invest in fleet testing, monitoring, and phased rollouts

Ensure high quality data

Secure default settings

Defense in depth requires us to layer our security defenses such that an attacker would need to pass multiple controls in an attack. To uphold this defensive position at scale, we centrally manage and measure various qualities of our devices, covering all layers of the platform;

Hardware/firmware configuration

Operating system and software

User settings and modifications

We use automated configuration management systems to continuously enforce our security and compliance policies. Independently, we observe the state of our hardware and software. This allows us to determine divergence from the expected state and verify whether it is an anomaly.

Where possible, our platforms use native OS capabilities to protect against malicious software, and we extend those capabilities across our platforms with custom and commercial tooling.
Scalable process
Google manages a fleet of several hundred thousand client devices (workstations, laptops, mobile devices) for employees who are spread across the world. We scale the engineering teams who manage these devices by relying on reviewable, repeatable, and automated backend processes and minimizing GUI-based configuration tools. By using and developing open-source software and integrating it with internal solutions, we reach a level of flexibility that allows us to manage fleets at scale without sacrificing customizability for our users. The focus is on operating system agnostic server and client solutions, where possible, to avoid duplication of effort.

Software for all platforms is provided by repositories which verify the integrity of software packages before making them available to users. The same system is used for distributing configuration settings and management tools, which enforce policies on client systems using the open-source configuration management system Puppet, running in standalone mode. In combination, this allows us to easily scale infrastructure and management horizontally as described in more detail and with examples in one of our BeyondCorp whitepapers, Fleet Management at Scale.

All device management policies are stored in centralized systems which allow settings to be applied both at the fleet and the individual device level. This way policy owners and device owners can manage sensible defaults or per-device overrides in the same system, allowing audits of settings and exceptions. Depending on the type of exception, they may either be managed self-service by the user, require approval from appropriate parties, or affect the trust level of the affected device. This way, we aim to guarantee user satisfaction and security simultaneously.

Fleet testing, monitoring, and phased rollouts

Applying changes at scale to a large heterogeneous fleet can be challenging. At Google, we have automated test labs which allow us to test changes before we deploy them to the fleet. Rollouts to the client fleet usually follow multiple stages and random canarying, similar to common practices with service management. Furthermore, we monitor various status attributes of our fleet which allows us to detect issues before they spread widely.

High quality data

Device management depends on the quality of device data. Both configuration and trust decisions are keyed off of inventory information. At Google, we track all devices in centralized asset management systems. This allows us to not only observe the current (runtime) state of a device, but also whether it’s a legitimate Google device. These systems store hardware attributes as well as the assignment and status of devices, which lets us match and compare prescribed values to those which are observed.

Prior to implementing BeyondCorp, we performed a fleet-wide audit to ensure the quality of inventory data, and we perform smaller audits regularly across the fleet. Automation is key to achieving this, both for entering data initially and for detecting divergence at later points. For example, instead of having a human enter data into the system manually, we use digital manifests and barcode scanners as much as possible.

How do we figure out whether devices are trustworthy?

After appropriate management systems have been put in place, and data quality goals have been met, the pertinent security information related to a device can be used to establish a "trust" decision as to whether a given action should be allowed to be performed from the device.

High level architecture for BeyondCorp
This decision can be most effectively made when an abundance of information about the device is readily available. At Google, we use an aggregated data pipeline to gather information from various sources, which each contain a limited subset of knowledge about a device and its history, and make this data available at the point when a trust decision is being made.
Various systems and repositories are employed within Google to perform collection and storage of device data that is relevant to security. These include tools like asset management repositories, device management solutions, vulnerability scanners, and internal directory services, which contain information and state about the multitude of physical device types (e.g., desktops, laptops, phones, tablets), as well as virtual desktops, used by employees at the company.

Having data from these various types of information systems available when making a trust decision for a given device can certainly be advantageous. However, challenges can present themselves when attempting to correlate records from a diverse set of systems which may not have a clear, consistent way to reference the identity of a given device. The challenge of implementation has been offset by the gains in security policy flexibility and improvements in securing our data.
What lessons did we learn?
As we rolled out BeyondCorp, we iteratively improved our fleet management and inventory processes as outlined above. These improvements are based on various lessons we learned around data quality challenges.

Audit your data ahead of implementing BeyondCorp

Data quality issues and inaccuracies are almost certain to be present in an asset management system of any substantial size, and these issues must be corrected before the data can be utilized in a manner which will have a significant impact on user experience. Having the means to compare values that have been manually entered into such systems against similar data that has been collected from devices via automation can allow for the correction of discrepancies, which may interrupt the intended behavior of the system.
Prepare to encounter unforeseen data quality challenges

Numerous data incorrectness scenarios and challenging issues are likely to present themselves as the reliance on accurate data increases. For example, be prepared to encounter issues with data ingestion processes that rely on transcribing device identifier information, which is physically labeled on devices or their packaging, and may incorrectly differ from identifier data that is digitally imprinted on the device.

In addition, over reliance on the assumed uniqueness of certain device identifiers can sometimes be problematic in the rare cases where conventionally unique attributes, like serial numbers, can appear more than once in the device fleet (this can be especially exacerbated in the case of virtual desktops, where such identifiers may be chosen by a user without regard for such concerns).

Lastly, routine maintenance and hardware replacements performed on employee devices can result in ambiguous situations with regards to the "identity" of a device. When internal device components, like network adapters or mainboards, are found to be defective and replaced, the device's identity can be changed into a state which no longer matches the known inventory data if care is not taken to correctly reflect such changes.

Implement controls to maintain high quality asset inventory

After inventory data has been brought to an acceptable correctness level, mechanisms should be put into place to limit the ability for new inaccuracies to be introduced. For example, at Google, data correctness checks have been integrated into the provisioning process for new devices so that inventory records must be correct before a device can be successfully imaged with an operating system, ensuring that the device will meet required data accuracy standards before being delivered to an employee.

Next time
In the next post in this series, we will discuss a tiered access approach, how to create rule-based trust and the lessons we’ve learned through that process.

In the meantime, if you want to learn more, you can check out the BeyondCorp research papers. In addition, getting started with BeyondCorp is now easier using zero trust solutions from Google Cloud (context-aware access) and other enterprise providers.

Thank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).

New Research: Lessons from Password Checkup in action

15 اگست، 2019

Posted by Jennifer Pullman, Kurt Thomas, and Elie Bursztein, Spam and Abuse researchannouncedPassword Checkup extensionthird-party data breach

hereUSENIX Security SymposiumWhich accounts are most at risk?
strong, unique passwords for all your accounts

Anonymous telemetry reported by Password Checkup extension shows that users most often reuse vulnerable passwords on shopping, news, and entertainment sites.

Helping users re-secure their unsafe passwords

Improving the Password Checkup extension
here

Making authentication even easier with FIDO2-based local user verification for Google Accounts

12 اگست، 2019

Posted by Dongjing He, Software Engineer and Christiaan Brand, Product Manager
Passwords, combined with Google's automated protections, help secure billions of users around the world. But, new security technologies are surpassing passwords in terms of both strength and convenience. With this in mind, we are happy to announce that you can verify your identity by using your fingerprint or screen lock instead of a password when visiting certain Google services. The feature is available today on Pixel devices and coming to all Android 7+ devices over the next few days.

Simpler authentication experience when viewing your saved password for a website on passwords.google.comThese enhancements are built using the FIDO2 standards, W3C WebAuthn and FIDO CTAP, and are designed to provide simpler and more secure authentication experiences. They are a result of years of collaboration between Google and many other organizations in the FIDO Alliance and the W3C.

An important benefit of using FIDO2 versus interacting with the native fingerprint APIs on Android is that these biometric capabilities are now, for the first time, available on the web, allowing the same credentials be used by both native apps and web services. This means that a user only has to register their fingerprint with a service once and then the fingerprint will work for both the native application and the web service.

Note that your fingerprint is never sent to Google’s servers - it is securely stored on your device, and only a cryptographic proof that you’ve correctly scanned it is sent to Google’s servers. This is a fundamental part of the FIDO2 design.
Here is how it works

Google is using the FIDO2 capability on Android to register a platform-bound FIDO credential. We remember the credential for that specific Android device. Now, when the user visits a compatible service, such as passwords.google.com, we issue a WebAuthn “Get” call, passing in the credentialId that we got when creating the credential. The result is a valid FIDO2 signature.

High-level architecture of using fingerprint or screen lock on Android devices to verify a user’s identity without a password

Please follow the instructions below if you’d like to try it out.
Prerequisites

Phone is running Android 7.0 (Nougat) or later
Your personal Google Account is added to your Android device
Valid screen lock is set up on your Android device

To try it

Open the Chrome app on your Android device
Navigate to https://passwords.google.com
Choose a site to view or manage a saved password
Follow the instructions to confirm that it’s you trying signing in

You can find more detailed instructions here.

For additional security
Remember, Google's automated defenses securely block the overwhelming majority of sign-in attempts even if an attacker has your username or password. Further, you can protect your accounts with two-step verification (2SV), including Titan Security Keys and Android phone’s built-in security key.

Both security keys and local user verification based on biometrics use the FIDO2 standards. However, these two protections address different use cases. Security keys are used for bootstrapping a new device as a second factor as part of 2SV in order to make sure it’s the right owner of the account accessing it. Local user verification based on biometrics comes after bootstrapping a device and can be used for re-authentication during step-up flows to verify the identity of the already signed-in user.

What’s next
This new capability marks another step on our journey to making authentication safer and easier for everyone to use. As we continue to embrace the FIDO2 standard, you will start seeing more places where local alternatives to passwords are accepted as an authentication mechanism for Google and Google Cloud services. Check out this presentation to get an early glimpse of the use cases that we are working to enable next.

Awarding Google Cloud Vulnerability Research

8 اگست، 2019

Posted by Felix Groebert, Information Security Engineeringg.co/vulnzhereVulnerability Research Grants Programup to tens of thousands of dollars per bugPwniumProject Zero Prizeherefree tier of GCP

Understanding why phishing attacks are so effective and how to mitigate them

8 اگست، 2019

Posted by Elie Bursztein, Security & Anti-abuse Research Lead, Daniela Oliveira, Professor at the University of Florida

Phishing attacks continue to be one of the common forms of account compromise threats. Every day, Gmail blocks more than 100 million phishing emails and Google Safe Browsing helps protect more than 4 billion devices against dangerous sites.
As part of our ongoing efforts to further protect users from phishing, we’re partnering with Daniela Oliveira from the University of Florida during a talk at Black Hat 2019 to explore the reasons why social engineering attacks remain effective phishing tactics, even though they have been around for decades.

Overall, the research finds there are a few key factors that make phishing an effective attack vector:

Phishing is constantly evolving: 68% of the phishing emails blocked by Gmail today are new variations that were never seen before. This fast pace adversarial evolution requires humans and machines to adapt very quickly to prevent them.

Phishing is targeted: Many of the campaigns targeting Gmail end-users and enterprise consumers only target a few dozen individuals. Enterprise users being 4.8x more targeted than end-users.

Phishers are persuasion experts: As highlighted by Daniela’s research with Natalie Ebner et al. at the University of Florida, phishers have mastered the use of persuasion techniques, emotional salience and gain or loss framing to trick users into reacting to phishing emails.

45% of users don’t understand what phishing is: After surveying Internet users, we found that 45% of them do not understand what phishing is or the risk associated with it. This lack of awareness increases the risk of being phished and potentially hinders the adoption of 2-step verification.

Protecting users against phishing requires a layered defense approach that includes:

Educating users about phishing so they understand what it is, how to detect it and how to protect themselves.

Leveraging the recent advances in AI to build robust phishing detections that can keep pace with fast evolving phishing campaigns.

Displaying actionable phishing warnings that are easy to understand by users so they know how to react when they see them.

Using strong two factor authentication makes it more difficult for phishers to compromise accounts. Two-factor technologies, as visible in the graph above, can be effective against the various forms of phishing, which highlights the importance of driving awareness and adoption among users.

While technologies to help mitigate phishing exist, such as FIDO standard security keys, there is still work to be done to help users increase awareness understand how to protect themselves against phishing.

Adopting the Arm Memory Tagging Extension in Android

2 اگست، 2019

Posted by Kostya Serebryany, Google Core Systems, and Sudhi Herle, Android Security & Privacy Team 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:

Precise mode: Provides more detailed information about the memory violation

Imprecise mode: Has lower CPU overhead and is more suitable to be always-on.

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.

MTE provides a version of ASAN/HWASAN that is easier to use for testing and fuzzing in laboratory environments. It will find more bugs in a fraction of the time and at a lower cost, reducing the complexity of the development process. In many cases, MTE will allow testing memory safety using the same binary as shipped to production. The bug reports produced by MTE will be as detailed and actionable as those from ASAN and HWASAN.

MTE will be used as a mechanism for testing complex software scenarios in production. App Developers and OEMs will be able to selectively turn on MTE for parts of the software stack. Where users have provided consent, bug reports will be available to developers via familiar mechanisms like Google Play Console.

MTE can be used as a strong security mitigation in the Android System and applications for many classes of memory safety bugs. For most instances of such vulnerabilities, a probabilistic mitigation based on MTE could prevent exploitation with a higher than 90% chance of detecting each invalid memory access. By implementing these protections and ensuring that attackers can't make repeated attempts to exploit security-critical components, we can significantly reduce the risk to users posed by memory safety issues.

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.

Titan Security Keys are now available in Canada, France, Japan, and the UK

31 جولائی، 2019

Posted by Christiaan Brand, Product Manager, Google Cloud
Credential compromise as a result of phishing is one of the most common causes of security breaches. Security keys provide the strongest protection against these types of attacks, and that’s one of the main reasons why Google requires them as a second factor of authentication for our employees.
Last year, we launched Titan Security Keys in the United States and were excited to see strong demand from users and businesses choosing to protect their personal and work Google Accounts. Starting today, Titan Security Keys are also available on the Google Store in Canada, France, Japan, and the United Kingdom (UK).

Titan Security Keys

Titan Security Keys are built with a hardware chip that includes firmware engineered by Google to verify the keys’ integrity. Each key leverages FIDO standards to cryptographically verify your identity and URL of the login page, preventing an attacker from accessing your account even if you are tricked into providing your username and password. Security keys are appropriate for any security-conscious user or enterprise, and we recommend that all users, especially those at higher risk such as IT administrators, executives, politicians, and activists consider signing in via security keys.

Bundles of two Titan Security Keys (one USB/NFC and one Bluetooth) are available on the Google Store in Canada, France, Japan, and the UK in addition to the US. To set up your security keys with your personal or work Google Account, sign in and navigate to the 2-Step Verification page. In addition, you can enroll in the Advanced Protection Program, which provides Google’s strongest security for anyone at risk of targeted attacks. Titan Security Keys can also be used anywhere FIDO security keys are supported, including Coinbase, Dropbox, Facebook, GitHub, Salesforce, Stripe, Twitter, and more

Enterprise administrators can require security keys for their users in G Suite and Google Cloud Platform (GCP). Bulk orders of unbundled Titan Security Keys are available in Canada, Japan, and the US.

Chrome Fuzzer Program Update And How-To

30 جولائی، 2019

Posted by Max Moroz, Fuzzing Evangelist, and Ned Williamson, Fuzzing Entrepreneur 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:

Fuzzing documentation

Existing fuzz targets

Fuzzing coverage dashboard

Medium+ severity bugs reported via Chrome VRP

Happy fuzzing and bug hunting!

Security Blog