Google Security Blog

Amy Ressler, Chrome Security Team on behalf of the Chrome VRP

For 13 years, a key pillar of the Chrome Security ecosystem has included encouraging security researchers to find security vulnerabilities in Chrome browser and report them to us, through the Chrome Vulnerability Rewards Program.

Starting today and until 1 December 2023, the first security bug report we receive with a functional full chain exploit, resulting in a Chrome sandbox escape, is eligible for triple the full reward amount. Your full chain exploit could result in a reward up to $180,000 (potentially more with other bonuses).

Any subsequent full chains submitted during this time are eligible for double the full reward amount!

We have historically put a premium on reports with exploits – “high quality reports with a functional exploit” is the highest tier of reward amounts in our Vulnerability Rewards Program. Over the years, the threat model of Chrome browser has evolved as features have matured and new features and new mitigations, such a MiraclePtr, have been introduced. Given these evolutions, we’re always interested in explorations of new and novel approaches to fully exploit Chrome browser and we want to provide opportunities to better incentivize this type of research. These exploits provide us valuable insight into the potential attack vectors for exploiting Chrome, and allow us to identify strategies for better hardening specific Chrome features and ideas for future broad-scale mitigation strategies.

The full details of this bonus opportunity are available on the Chrome VRP rules and rewards page. The summary is as follows:

• The bug reports may be submitted in advance while exploit development continues during this 180-day window. The functional exploits must be submitted to Chrome by the end of the 180-day window to be eligible for the triple or double reward.
  • The first functional full chain exploit we receive is eligible for the triple reward amount.
• The full chain exploit must result in a Chrome browser sandbox escape, with a demonstration of attacker control / code execution outside of the sandbox.
• Exploitation must be able to be performed remotely and no or very limited reliance on user interaction.
• The exploit must have been functional in an active release channel of Chrome (Dev, Beta, Stable, Extended Stable) at the time of the initial reports of the bugs in that chain. Please do not submit exploits developed from publicly disclosed security bugs or other artifacts in old, past versions of Chrome.

As is consistent with our general rewards policy, if the exploit allows for remote code execution (RCE) in the browser or other highly-privileged process, such as network or GPU process, to result in a sandbox escape without the need of a first stage bug, the reward amount for renderer RCE “high quality report with functional exploit” would be granted and included in the calculation of the bonus reward total.

Based on our current Chrome VRP reward matrix, your full chain exploit could result in a total reward of over $165,000 -$180,000 for the first full chain exploit and over $110,000 - $120,000 for subsequent full chain exploits we receive in the six month window of this reward opportunity.

We’d like to thank our entire Chrome researcher community for your past and ongoing efforts and security bug submissions! You’ve truly helped us make Chrome more secure for all users.

Happy Hunting!

Posted by Ashish Pujari, Chrome Security Team

Introduction

Chrome is trusted by millions of business users as a secure enterprise browser. Organizations can use Chrome Browser Cloud Management to help manage Chrome browsers more effectively. As an admin, they can use the Google Admin console to get Chrome to report critical security events to third-party service providers such as Splunk® to create custom enterprise security remediation workflows.

Security remediation is the process of responding to security events that have been triggered by a system or a user. Remediation can be done manually or automatically, and it is an important part of an enterprise security program.

Why is Automated Security Remediation Important?

When a security event is identified, it is imperative to respond as soon as possible to prevent data exfiltration and to prevent the attacker from gaining a foothold in the enterprise. Organizations with mature security processes utilize automated remediation to improve the security posture by reducing the time it takes to respond to security events. This allows the usually over burdened Security Operations Center (SOC) teams to avoid alert fatigue.

Automated Security Remediation using Chrome Browser Cloud Management and Splunk

Chrome integrates with Chrome Enterprise Recommended partners such as Splunk® using Chrome Enterprise Connectors to report security events such as malware transfer, unsafe site visits, password reuse. Other supported events can be found on our support page.

The Splunk integration with Chrome browser allows organizations to collect, analyze, and extract insights from security events. The extended security insights into managed browsers will enable SOC teams to perform better informed automated security remediations using Splunk® Alert Actions.

Splunk Alert Actions are a great capability for automating security remediation tasks. By creating alert actions, enterprises can automate the process of identifying, prioritizing, and remediating security threats.

In Splunk®, SOC teams can use alerts to monitor for and respond to specific Chrome Browser Cloud Management events. Alerts use a saved search to look for events in real time or on a schedule and can trigger an Alert Action when search results meet specific conditions as outlined in the diagram below.

Use Case

If a user downloads a malicious file after bypassing a Chrome “Dangerous File” message their managed browser/managed CrOS device should be quarantined.

Prerequisites

• Create a Chrome Browser Cloud Management account at no additional costs
• Splunk® Enterprise v9.0.* or Splunk® Cloud Platform (Cost: Please refer to Splunk’s website)
• Understanding of the Splunk alerting workflow
• Understanding of how to create custom alert actions in Splunk®.

Setup

1. Install the Google Chrome Add-on for Splunk App

   Please follow installation instructions here depending on your Splunk Installation to install the Google Chrome Add-on for Splunk App.

2. Setting up Chrome Browser Cloud Management and Splunk Integration

   Please follow the guide here to set up Chrome Browser Cloud Management and Splunk® integration.

3. Setting up Chrome Browser Cloud Management API access

   To call the Chrome Browser Cloud Management API, use a service account properly configured in the Google admin console. Create a (or use an existing) service account and download the JSON representation of the key.

   Create a (or use an existing) role in the admin console with all the “Chrome Management” privileges as shown below.

   Assign the created role to the service account using the “Assign service accounts” button.
   

4. Setting up Chrome Browser Cloud Management App in Splunk®

   Install the App i.e. Alert Action from our Github page. You will notice that the Splunk App uses the below directory structure. Please take some time to understand the directory structure layout.

5. Setting up a Quarantine OU in Chrome Browser Cloud Management

   Create a “Quarantine” OU to move managed browsers into. Apply restrictive policies to this OU which will then be applied to managed browsers and managed CrOS devices that are moved to this OU. In our case we set the below policies for our “Quarantine” OU called Investigate.These policies ensure that the quarantined CrOS device/browser can only open a limited set of approved URLS.

   • URL Blocklist - Block access to all URLs
   • URL Allowlist - Allow only approved URLs for e.g. IT Helpdesk website
   • New Tab Page Location - Set New tab page URL to an internal website asking the user to contact IT Helpdesk.
   • Home Page is New Tab Page - Use the New Tab page as the user's homepage.

Configuration

1. Start with a search for the Chrome Browser Cloud Management events in the Google Chrome Add-on for Splunk App. For our instance we used the below search query to search for known malicious file download events.
2. Save the search as an alert. The alert uses the saved search to check for events. Adjust the alert type to configure how often the search runs. Use a scheduled alert to check for events on a regular basis. Use a real-time alert to monitor for events continuously. An alert does not have to trigger every time it generates search results. Set trigger conditions to manage when the alert triggers. Customize the alert settings as per enterprise security policies. For our example we used a real time alert with a per-result trigger. The setup we used is as shown below.

As seen in the screenshot we have configured the Chrome Browser Cloud Management Remediation Alert Action App with

• The OU Path of the Quarantine OU i.e. /Investigate
• The Customer Id of the workspace domain
• Service Account Key JSON value

Test the setup

Use the testsafebrowsing website to generate sample security events to test the setup.

1. Open the testsafebrowsing website
2. Click the link for line item 4 under the Desktop Download Warnings section i.e. “Should show an "uncommon" warning, for .exe”
3. You will see a Dangerous Download blocked warning giving you two options to either Discard or Keep the downloaded file. Click on Keep
4. This will trigger the alert action and move your managed browser or managed CrOS device to the “Quarantine” OU (OU name Investigate in our example) with restricted policies.

Conclusion

Security remediation is vital to any organization’s security program. In this blog we discussed configuring automated security remediation of Chrome Browser Cloud Management security events using Splunk alert actions. This scalable approach can be used to protect a company from online security threats by detecting and quickly responding to high fidelity Chrome Browser Cloud Management security events thereby greatly reducing the time to respond.

Our team will be at the Gartner Security and Risk Management Summit in National Harbor, MD, next week. Come see us in action if you’re attending the summit.

Vincent Winstead, Technical Program Manager

It’s Google CTF time! Get your hacking toolbox ready and prepare your caffeine for rapid intake. The competition kicks off on June 23 2023 6:00 PM UTC and runs through June 25 2023 6:00 PM UTC. Registration is now open at g.co/ctf.

Google CTF gives you a chance to challenge your skillz, show off your hacktastic abilities, and learn some new tricks along the way. It consists of a set of computer security puzzles (or challenges) involving reverse-engineering, memory corruption, cryptography, web technologies, and more. Use obscure security knowledge to find exploits through bugs and creative misuse. With each completed challenge your team will earn points and move up through the ranks. 

The top 8 teams will qualify for our Hackceler8 competition taking place in Tokyo later this year. Hackceler8 is our experimental esport-style hacking game, custom-made to mix CTF and speedrunning. In the competition, teams need to find clever ways to abuse the game features to capture flags as quickly as possible. See the 2022 highlight reel to get a sense of what it’s like. The prize pool for this year’s event stands at more than $32,000!

Screenshot from Hackeler8 2022 speedrun competition

Itching to get started early? Want to learn more, or get a leg up on the competition? Review challenges from previous years, including previous Hackceler8 matches, all open sourced on GitHub. Or gain inspiration by binge watching hours of Hackceler8 2020 videos!

If you are just starting out in this space, check out last year’s event H4CK1NG GOOGLE! It’s a great way to get acquainted with security. You can also get ready for this year’s Beginner’s Quest that’ll be launching later this summer which will be in the theme of Computer History, so get ready for some technology archaeology.

Whether you’re a seasoned CTF player or just curious about cyber security and ethical hacking, we want you to join us. Sign up to expand your skill set, meet new friends in the security community, and even watch the pros in action. For the latest announcements, see g.co/ctf, subscribe to our mailing list, or follow us on Twitter @GoogleVRP. Interested in bug hunting for Google? Check out bughunters.google.com. See you there!

Vincent Winstead, Technical Program Manager



It’s Google CTF time! Get your hacking toolbox ready and prepare your caffeine for rapid intake. The competition kicks off on June 23 2023 6:00 PM UTC and runs through June 25 2023 6:00 PM UTC. Registration is now open at g.co/ctf.

Google CTF gives you a chance to challenge your skillz, show off your hacktastic abilities, and learn some new tricks along the way. It consists of a set of computer security puzzles (or challenges) involving reverse-engineering, memory corruption, cryptography, web technologies, and more. Use obscure security knowledge to find exploits through bugs and creative misuse. With each completed challenge your team will earn points and move up through the ranks. 

The top 8 teams will qualify for our Hackceler8 competition taking place in Tokyo later this year. Hackceler8 is our experimental esport-style hacking game, custom-made to mix CTF and speedrunning. In the competition, teams need to find clever ways to abuse the game features to capture flags as quickly as possible. See the 2022 highlight reel to get a sense of what it’s like. The prize pool for this year’s event stands at more than $32,000!

Screenshot from Hackeler8 2022 speedrun competition

Itching to get started early? Want to learn more, or get a leg up on the competition? Review challenges from previous years, including previous Hackceler8 matches, all open-sourced here. Or gain inspiration by binge watching hours of Hackceler8 2020 videos!

If you are just starting out in this space, check out last year’s event H4CK1NG GOOGLE! It’s a great way to get acquainted with security. You can also get ready for this year’s Beginner’s Quest that’ll be launching later this summer which will be in the theme of Computer History, so get ready for some technology archaeology.

Whether you’re a seasoned CTF player or just curious about cyber security and ethical hacking, we want you to join us. Sign up to expand your skill set, meet new friends in the security community, and even watch the pros in action. For the latest announcements, see g.co/ctf, subscribe to our mailing list, or follow us on Twitter @GoogleVRP. Interested in bug hunting for Google? Check out bughunters.google.com. See you there!

David Kluge, Technical Program Manager, and Andy Warner, Product Manager

Nobody likes preventable site errors, but they happen disappointingly often. 

The last thing you want your customers to see is a dreaded 'Your connection is not private' error instead of the service they expected to reach. Most certificate errors are preventable and one of the best ways to help prevent issues is by automating your certificate lifecycle using the ACME standard. Google Trust Services now offers our ACME API to all users with a Google Cloud account (referred to as “users” here), allowing them to automatically acquire and renew publicly-trusted TLS certificates for free. The ACME API has been available as a preview and over 200 million certificates have been issued already, offering the same compatibility as major Google services like google.com or youtube.com.

The Automatic Certificate Management Environment (ACME) protocol enables users to easily automate their TLS certificate lifecycle using a standards based API supported by dozens of clients to maintain certificates. ACME has become the de facto standard for certificate management on the web and has helped broaden adoption of TLS. The majority of all TLS certificates in the WebPKI today are issued by ACME CAs. ACME users experience fewer service outages caused by expired certificates by using ACME's automated certificate renewal capabilities. Manual certificate updates are a common source of outages, even for major online services. Sites already using ACME can configure multiple ACME providers to increase resilience during CA outages or mass renewal events.

What customers say

During the preview phase, the ACME endpoint has already been used extensively. The number of certificates requested by our users has driven up the GTS issuance volume to the fourth largest publicly trusted Certificate Authority.

"At Cloudflare, we believe encryption should be free for all; we pioneered that for all our customers back in 2014 when we included encryption for free in all our products. We're glad to see Google join the ranks of certificate authorities that believe encryption should be free for everyone, and we're proud to offer Google as a CA choice for our customers. Their technical expertise guarantees they'll be able to scale to meet the needs of an increasingly encrypted Internet," says Matthew Prince, CEO, Cloudflare.

Making the Web Safer

The Google Trust Services ACME API was introduced last year as a preview. The service recently expanded support for Google Domains customers. By further opening up the service, we're adding another tool to Google’s Cyber Security Advancements, keeping individuals, businesses, and governments safer online through highly trusted and free certificates. We're also introducing two significant features that further enhance the certificate ecosystem: ACME Renewal Information (ARI) and Multi-perspective Domain Validation. ARI is a new standard to help manage renewals that we're excited to support. General availability of multi-perspective domain validation brings the benefits of years of work to increase the security of Google's certificates for all users.

ACME Renewal Information (ARI)

ACME Renewal Information (ARI) addresses the longstanding challenge of knowing when a certificate must be replaced before its standard renewal period via an API.

ARI is an Internet Engineering Task Force (IETF) Internet Draft authored by Let’s Encrypt as an extension to the ACME protocol. It helps service operators automatically replace their certificates in case revocation must occur before the certificate expires. 

Serving certificate renewal information via ACME is particularly useful for managing large certificate populations. ARI could have potentially made a difference in past certificate replacement events affecting large parts of the WebPKI, including the 2019 serial number entropy bug affecting multiple CAs which forced rapid replacement of hundreds of thousands of certificates.

Multi-Perspective Domain Validation

Multi-perspective domain validation (MPDV), enhances the validation process for certificate issuance. Publicly-trusted CAs, like Google Trust Services, ensure only authorized requesters can obtain certificates for a given domain name by confirming the requester can prove control over the domain via validation challenges. Domain validation provides a high level of assurance under normal conditions. However, domain control validation methods can be vulnerable to attacks such as DNS cache poisoning and Border Gateway Protocol (BGP) hijacking.

With MPDV, domain control verification is performed from multiple locations, referred to as “network perspectives.” Using multiple perspectives significantly improves the reliability of validation by preventing localized attacks from being able to fool validation checks. Let’s Encrypt adopted the first at-scale MPDV implementation, which performed the validation from three different network perspectives and required a quorum before issuance.

Our approach is similar. We also require a quorum of different network perspectives, but thanks to the scale and reach of our infrastructure, we have thousands of egress points forming “regional perspectives” that deter attackers from compromising enough targets to secure an invalid validation.

How do I use it?
Please see the Public CA Tutorial. The ACME API is free and available to anyone with a Google Cloud account. More information is available at pki.goog.

Brandon Lum and Mihai Maruseac, Google Open Source Security Team

Today, we are announcing the launch of the v0.1 version of Graph for Understanding Artifact Composition (GUAC). Introduced at Kubecon 2022 in October, GUAC targets a critical need in the software industry to understand the software supply chain. In collaboration with Kusari, Purdue University, Citi, and community members, we have incorporated feedback from our early testers to improve GUAC and make it more useful for security professionals. This improved version is now available as an API for you to start developing on top of, and integrating into, your systems.

The need for GUAC

High-profile incidents such as Solarwinds, and the recent 3CX supply chain double-exposure, are evidence that supply chain attacks are getting more sophisticated. As highlighted by the U.S. Executive Order on Cybersecurity, there’s a critical need for security professionals, CISOs, and security engineers to be able to more deeply link information from different supply chain ecosystems to keep up with attackers and prevent exposure. Without linking different sources of information, it’s impossible to have a clear understanding of the potential risks posed by the software components in an organization. 

GUAC aggregates software security metadata and maps it to a standard vocabulary of concepts relevant to the software supply chain. This data can be accessed via a GraphQL interface, allowing development of a rich ecosystem of integrations, command-line tools, visualizations, and policy engines. 

We hope that GUAC will help the wider software development community better evaluate the supply chain security posture of their organizations and projects. Feedback from early adopters has been overwhelmingly positive: 

“At Yahoo, we have found immense value and significant efficiency by utilizing the open source project GUAC. GUAC has allowed us to streamline our processes and increase efficiency in a way that was not possible before,” said Hemil Kadakia, Sr. Mgr. Software Dev Engineering, Paranoids, Yahoo.

The power of GUACDynamic aggregationGUAC is not just a static database—it is the first application that is continuously evolving the database pertaining to the software that an organization develops or uses. Supply chains change daily, and by aggregating your Software Bill of Materials (SBOMs) and Supply-chain Levels for Software Artifacts (SLSA) attestations with threat intelligence sources (e.g., OSV vulnerability feeds) and OSS insights (e.g., deps.dev), GUAC is constantly incorporating the latest threat information and deeper analytics to help paint a more complete picture of your risk profile. And by merging external data with internal private metadata, GUAC brings the same level of reasoning to a company’s first-party software portfolio.


Seamless integration of incomplete metadataBecause of the complexity of the modern software stack—often spanning languages and toolchains—we discovered during GUAC development that it is difficult to produce high-quality SBOMs that are accurate, complete, and meet specifications and intents. 

Following the U.S. Executive Order on Cybersecurity, there are now a large number of SBOM documents being generated during release and build workflows to explain to consumers what’s in their software. Given the difficulty in producing accurate SBOMs, consumers often face a situation where they have incomplete, inaccurate, or conflicting SBOMs. In these situations, GUAC can fill in the gaps in the various supply chain metadata: GUAC can link the documents and then use heuristics to improve the quality of data and guess at the correct intent. Additionally, the GUAC community is now working closely with SPDX to advance SBOM tooling and improve the quality of metadata. 

  

GUAC's process for incorporating and enriching metadata for organizational insightConsistent interfaces

Alongside the boom in SBOM production, there’s been a rapid expansion of new standards, document types, and formats, making it hard to perform consistent queries. The multiple formats for software supply chain metadata often refer to similar concepts, but with different terms. To integrate these, GUAC defines a common vocabulary for talking about the software supply chain—for example, artifacts, packages, repositories, and the relationships between them. 

This vocabulary is then exposed as a GraphQL API, empowering users to build powerful integrations on top of GUAC’s knowledge graph. For example, users are able to query seamlessly with the same commands across different SBOM formats like SPDX and CycloneDX. 

According to Ed Warnicke, Distinguished Engineer at Cisco Systems, "Supply chain security is increasingly about making sense of many different kinds of metadata from many different sources. GUAC knits all of that information together into something understandable and actionable." 

Potential integrations

Based on these features, we envision potential integrations that users can build on top of GUAC in order to:

• Create policies based on trust

• Quickly react to security compromises 

• Determine an upgrade plan in response to a security incident

• Create visualizers for data explorations, CLI tools for large scale analysis and incident response, CI checks, IDE plugins to shift policy left, and more

Developers can also build data source integrations under GUAC to expand its coverage. The entire GUAC architecture is plug-and-play, so you can write data integrations to get:

• Supply chain metadata from new sources like your preferred security vendors

• Parsers to translate this metadata into the GUAC ontology

• Database backends to store the GUAC data in either common databases or in organization-defined private data stores

GUAC's GraphQL query API enables a diverse ecosystem of tooling

Dejan Bosanac, an engineer at Red Hat and an active contributor to the GUAC project, further described GUAC’s ingestion abilities, “With mechanisms to ingest and certify data from various sources and GraphQL API to later query those data, we see it as a good foundation for our current and future SSCS efforts. Being a true open source initiative with a welcoming community is just a plus.” 

Next steps

Google is committed to making GUAC the best metadata synthesis and aggregation tool for security professionals. GUAC contributors are excited to meet at our monthly community calls and look forward to seeing demos of new applications built with GUAC.

“At Kusari, we are proud to have joined forces with Google's Open Source Security Team and the community to create and build GUAC,” says Tim Miller, CEO of Kusari. “With GUAC, we believe in the critical role it plays in safeguarding the software supply chain and we are dedicated to ensuring its success in the ecosystem.” 

Google is preparing SBOMs for consumption by the US Federal Government following EO 14028, and we are internally ingesting our SBOM catalog into GUAC to gather early insights. We encourage you to do the same with the GUAC release and submit your feedback. If the API is not flexible enough, please let us know how we can extend it. You can also submit suggestions and feedback on GUAC development or use cases, either by emailing guac-maintainers@googlegroups.com or filing an issue on our GitHub repository.

We hope you'll join us in this journey with GUAC!

Posted by Chrome Root Program, Chrome Security Team

What is the Chrome Root Program?

A root program is one of the foundations for securing connections to websites. The Chrome Root Program was announced in September 2022. If you missed it, don’t worry - we’ll give you a quick summary below!

Chrome Root Program: TL;DR

Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes for its users are secure and private. Certificates are issued by trusted entities called “Certification Authorities” (CAs). The collection of digital certificates, CA systems, and other related online services is the foundation of HTTPS and is often referred to as the “Web PKI.”

Before issuing a certificate to a website, the CA must verify that the certificate requestor legitimately controls the domain whose name will be represented in the certificate. This process is often referred to as “domain validation” and there are several methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence. Typically, domain validation practices must conform with a set of security requirements described in both industry-wide and browser-specific policies, like the CA/Browser Forum “Baseline Requirements” and the Chrome Root Program policy.

Upon connecting to a website, Chrome verifies that a recognized (i.e., trusted) CA issued its certificate, while also performing additional evaluations of the connection’s security properties (e.g., validating data from Certificate Transparency logs). Once Chrome determines that the certificate is valid, Chrome can use it to establish an encrypted connection to the website. Encrypted connections prevent attackers from being able to intercept (i.e., eavesdrop) or modify communication. In security speak, this is known as confidentiality and integrity.

The Chrome Root Program, led by members of the Chrome Security team, provides governance and security review to determine the set of CAs trusted by default in Chrome. This set of so-called "root certificates" is known at the Chrome Root Store.

How does the Chrome Root Program keep users safe?

The Chrome Root Program keeps users safe by ensuring the CAs Chrome trusts to validate domains are worthy of that trust. We do that by:

• administering policy and governance activities to manage the set of CAs trusted by default in Chrome,
• evaluating impact and corresponding security implications related to public security incident disclosures by participating CAs, and
• leading positive change to make the ecosystem more resilient.

Policy and Governance

The Chrome Root Program policy defines the minimum requirements a CA owner must meet for inclusion in the Chrome Root Store. It incorporates the industry-wide CA/Browser Forum Baseline Requirements and further adds security controls to improve Chrome user security.

The CA application process includes a public discussion phase, where members of the Web PKI community are free to raise well-founded, fact-based concerns related to an applicant on an open discussion forum.

We consider public discussion valuable because it:

• improves security, transparency, and interoperability, and
• highlights concerning behavior, practices, or ownership background information not readily available through public audits, policy reviews, or other application process inputs.

For a CA owner’s inclusion request to be accepted, it must clearly demonstrate that the value proposition for the security and privacy of Chrome’s end users exceeds the corresponding risk of inclusion.

Once a CA is trusted, it can issue certificates for any website on the internet; thus, each newly added CA represents an additional attack surface, and the Web PKI is only as safe as its weakest link. For example, in 2011 a compromised CA led to a large-scale attack on web users in Iran.

Incident Management

No CA is perfect. When a CA owner violates the Chrome Root Program policy – or experiences any other situation that affects the CA’s integrity, trustworthiness, or compatibility – we call it an incident. Incidents can happen. They are an expected part of building a secure Web PKI. All the same, incidents represent opportunities to improve practices, systems, and understanding. Our program is committed to continuous improvement and participates in a public Web PKI incident management process.

When incidents occur, we expect CA owners to identify the root cause and remediate it to help prevent similar incidents from happening again. CA owners record the incident in a report that the Chrome Root Program and the public can review, which encourages an understanding of all contributing factors to reduce the probability of its reoccurrence in the Web PKI.

The Chrome Root Program prioritizes the security and privacy of its users and is unwilling to compromise on these values. In rare cases, incidents may result in the Chrome Root Program losing confidence in the CA owner’s ability to operate securely and reliably. This may happen when there is evidence of a CA owner:

• knowingly violating requirements or obfuscating incidents,
• demonstrating sustained patterns of failure, untimely and opaque communications, or an unwillingness to improve elements that are critical to security, or
• performing other actions that negatively impact or otherwise degrade the security of the Web.

In these cases, Chrome may distrust a CA – that is, remove the CA from the Chrome Root Store. Depending on the circumstance, Chrome may also block the certificate with a non-bypassable error page.

The above cases are only illustrative, and considerations for CA distrust are not limited to these examples. The Chrome Root Program may remove certificates from the Chrome Root Store, as it deems appropriate and at its sole discretion, to enhance security and promote interoperability in Chrome.

Positive Ecosystem Change

The Chrome Root Program collaborates with members of the Web PKI ecosystem in various forums (e.g., the CA/Browser Forum) and committees (e.g., the CCADB Steering Committee). We share best practices, advocate for and develop new standards to promote user security, and seek ecosystem participant feedback on proposed initiatives. Collectively, ecosystem participants contributing to these working groups are protecting the Web.

In June 2022, we announced the “Moving Forward, Together” initiative that shared our vision of the future Web PKI that includes modern, reliable, agile, and purpose-driven architectures with a focus on automation, simplicity, and security. The initiative represents the goals and priorities of the Chrome Root Program and reinforces our commitment to working alongside CA owners to make the Web a safer place.

Some of our current priorities include:

• reducing misissuance of certificates that do not comply with the Baseline Requirements, a CA’s own policies, or the Chrome Root Program policy,
• increasing accountability and ecosystem integrity with high-quality, independent audits,
• automating certificate issuance and strengthening the domain validation process, and
• preparing for a “post-quantum” world.

We believe implementing proposals related to these priorities will help manage risk and make the Web a safer place for everyone.

However, as the name suggests, we can only realize these opportunities to improve with the collective contributions of the community. We understand CAs to be an essential element of the Web PKI, and we are encouraged by continued feedback and participation from existing and future CA owners in our program.

The Chrome Root Program is committed to openness and transparency, and we are optimistic we can achieve this shared vision. If you’re interested in seeing what new initiatives are being explored by the Chrome Root Program to keep Chrome users safe - you can learn more here.

Posted by Sarah Jacobus, Vulnerability Rewards Team

As technology continues to advance, so do efforts by cybercriminals who look to exploit vulnerabilities in software and devices. This is why at Google and Android, security is a top priority, and we are constantly working to make our products more secure. One way we do this is through our Vulnerability Reward Programs (VRP), which incentivize security researchers to find and report vulnerabilities in our operating system and devices.

We are pleased to announce that we are implementing a new quality rating system for security vulnerability reports to encourage more security research in higher impact areas of our products and ensure the security of our users. This system will rate vulnerability reports as High, Medium, or Low quality based on the level of detail provided in the report. We believe that this new system will encourage researchers to provide more detailed reports, which will help us address reported issues more quickly and enable researchers to receive higher bounty rewards.

The highest quality and most critical vulnerabilities are now eligible for larger rewards of up to $15,000!

There are a few key elements we are looking for:

Accurate and detailed description: A report should clearly and accurately describe the vulnerability, including the device name and version. The description should be detailed enough to easily understand the issue and begin working on a fix.

Root cause analysis: A report should include a full root cause analysis that describes why the issue is occurring and what Android source code should be patched to fix it. This analysis should be thorough and provide enough information to understand the underlying cause of the vulnerability.

Proof-of-concept: A report should include a proof-of-concept that effectively demonstrates the vulnerability. This can include video recordings, debugger output, or other relevant information. The proof-of-concept should be of high quality and include the minimum amount of code possible to demonstrate the issue.

Reproducibility: A report should include a step-by-step explanation of how to reproduce the vulnerability on an eligible device running the latest version. This information should be clear and concise and should allow our engineers to easily reproduce the issue and begin working on a fix.

Evidence of reachability: Finally, a report should include evidence or analysis that demonstrates the type of issue and the level of access or execution achieved.

*Note: This criteria may change over time. For the most up to date information, please refer to our public rules page.

Additionally, starting May 15th, 2023, Android will no longer assign Common Vulnerabilities and Exposures (CVEs) to most moderate severity issues. CVEs will continue to be assigned to critical and high severity vulnerabilities.

We believe that incentivizing researchers to provide high-quality reports will benefit both the broader security community and our ability to take action. We look forward to continuing to work with researchers to make the Android ecosystem more secure.

If you would like more information on the Android & Google Device Vulnerability Reward Program, please visit our public rules page to learn more!

Dongge Liu, Jonathan Metzman and Oliver Chang, Google Open Source Security Team

Google’s Open Source Security Team recently sponsored a fuzzing competition as part of ICSE’s Search-Based and Fuzz Testing (SBFT) Workshop. Our goal was to encourage the development of new fuzzing techniques, which can lead to the discovery of software vulnerabilities and ultimately a safer open source ecosystem. 

The competitors’ fuzzers were judged on code coverage and their ability to discover bugs: 

• HasteFuzz took the $11,337 prize for code coverage

• PASTIS and AFLrustrust tied for bug discovery and split the $11,337 prize

Competitors were evaluated using FuzzBench, Google’s open source platform for testing and comparing fuzzers. The platform boasts a wide range of real world benchmarks and vulnerabilities, allowing researchers to test their fuzzers in an authentic environment. We hope the results of the SBFT fuzzing competition will lead to more efficient fuzzers and eventually newly discovered vulnerabilities. 

A closer look at our winners

Eight teams submitted fuzzers to the final competition and an additional four industry fuzzers (AFL++, libFuzzer, Honggfuzz, and AFL) were included as controls to represent current practice. 

• Code coverage winner - HasteFuzz

HasteFuzz, is a modification of the widely used AFL++ fuzzer. HasteFuzz filters out potentially duplicate inputs to increase efficiency, making it able to cover more code in the 23-hour test window because it is not likely to be retracing its steps. AFL++ is already a strong fuzzer—it had the best code coverage of the industry fuzzers tested in this competition—and HasteFuzz’s filtering took it to the next level.

• Bug discovery winners - PASTIS and AFLrustrust

PASTIS makes use of multiple fuzzing engines that can independently cover different program locations, allowing PASTIS to find bugs quickly. AFLrustrust rewrites AFL++ on top of LibAFL, which is a library of features that allows you to customize existing fuzzers. AFLrustrust effectively prunes redundant test cases, improving its bug finding efficiency. Both PASTIS and AFLrustrust found 8 out of 15 possible bugs, with each fuzzer missing only one bug discovered by others. They both outperformed the industry fuzzers, which found 7 or fewer bugs under the same constraints.

Additional competitors, such as AFL+++ and AFLSmart++, also showed improvements over the industry controls, a result we had hoped for with the competition.

Fuzzing research continues

The innovation and improvement shown through the SBFT fuzzing competition is one example of why we have invested in the FuzzBench project. Since its launch in 2020, FuzzBench has significantly contributed to high-quality fuzzing research, conducting over 900 experiments and discussed in more than 100 academic papers. FuzzBench was provided as a resource for the SBFT competition, but it is also available to researchers every day as a service. If you are interested in testing your fuzzers on FuzzBench, please see our guide to adding your fuzzer.

FuzzBench is in active development. We’d welcome feedback from any current or prospective FuzzBench users, your responses to this survey can help us plan the future of FuzzBench.

The Google Open Source Security Team would like to thank the ICSE conference and the SBFT workshop for hosting the fuzzing competition. We also want to thank each participant for their hard work. Together, we continue to push the boundaries of software security and create a safer, more robust open source ecosystem. 

Juan José López Jaimez, Security Researcher and Meador Inge, Security Engineer

Today, we are announcing Buzzer, a new eBPF Fuzzing framework that aims to help hardening the Linux Kernel.

What is eBPF and how does it verify safety?

eBPF is a technology that allows developers and sysadmins to easily run programs in a privileged context, like an operating system kernel. Recently, its popularity has increased, with more products adopting it as, for example, a network filtering solution. At the same time, it has maintained its relevance in the security research community, since it provides a powerful attack surface into the operating system.

While there are many solutions for fuzzing vulnerabilities in the Linux Kernel, they are not necessarily tailored to the unique features of eBPF. In particular, eBPF has many complex security rules that programs must follow to be considered valid and safe. These rules are enforced by a component of eBPF referred to as the "verifier". The correctness properties of the verifier implementation have proven difficult to understand by reading the source code alone. 

That’s why our security team at Google decided to create a new fuzzer framework that aims to test the limits of the eBPF verifier through generating eBPF programs.

The eBPF verifier’s main goal is to make sure that a program satisfies a certain set of safety rules, for example: programs should not be able to write outside designated memory regions, certain arithmetic operations should be restricted on pointers, and so on. However, like all pieces of software, there can be holes in the logic of these checks. This could potentially cause unsafe behavior of an eBPF program and have security implications.

Introducing Buzzer a new way to fuzz eBPF

Buzzer aims to detect these errors in the verifier’s validation logic by generating a high volume of eBPF programs – around 35k per minute. It then takes each generated program and runs it through the verifier. If the verifier thinks it is safe, then the program is executed in a running kernel to determine if it is actually safe. Errors in the runtime behavior are detected through instrumentation code added by Buzzer.

It is with this technique that Buzzer found its first issue, CVE-2023-2163, an error in the branch pruning logic of the eBPF verifier that can cause unsafe paths to be overlooked, thus leading to arbitrary reading and writing of kernel memory. This issue demonstrates not only the complexity in the task that the verifier tries to accomplish (to make sure a program is safe in an efficient manner), but also how Buzzer can help researchers uncover complex bugs by automatically exploring corner cases in the verifier’s logic.

Additionally, Buzzer includes an easy to use eBPF generation library that makes it unique from other eBPF, or other general purpose Linux kernel fuzzers. By focusing on this particular technology, Buzzer is allowed to tailor its strategies to the eBPF features.

We are excited about the contributions Buzzer will make to the overall hardening of the Linux Kernel by making the eBPF implementation safer. Our team plans to develop some new features, such as the ability to run eBPF programs across distributed VMs. 

Now that the code is open source, we are looking for contributors! If you have any interesting ideas for a feature we could implement in Buzzer, let us know in our GitHub repository.

We look forward to hearing your ideas and making eBPF safer together! Let the fuzzing begin.

Posted by Ronnie Falcon, Product Manager

Android is built with multiple layers of security and privacy protections to help keep you, your devices, and your data safe. Most importantly, we are committed to transparency, so you can see your device safety status and know how your data is being used.

Android uses the best of Google’s AI and machine learning expertise to proactively protect you and help keep you out of harm’s way. We also empower you with tools that help you take control of your privacy.

I/O is a great moment to show how we bring these features and protections all together to help you stay safe from threats like phishing attacks and password theft, while remaining in charge of your personal data.

Safe Browsing: faster more intelligent protection

Android uses Safe Browsing to protect billions of users from web-based threats, like deceptive phishing sites. This happens in the Chrome default browser and also in Android WebView, when you open web content from apps.

Safe Browsing is getting a big upgrade with a new real-time API that helps ensure you’re warned about fast-emerging malicious sites. With the newest version of Safe Browsing, devices will do real-time blocklist checks for low reputation sites. Our internal analysis has found that a significant number of phishing sites only exist for less than ten minutes to try and stay ahead of block-lists. With this real-time detection, we expect we’ll be able to block an additional 25 percent of phishing attempts every month in Chrome and Android1.

Safe Browsing isn’t just getting faster at warning users. We’ve also been building in more intelligence, leveraging Google’s advances in AI. Last year, Chrome browser on Android and desktop started utilizing a new image-based phishing detection machine learning model to visually inspect fake sites that try to pass themselves off as legitimate log-in pages. By leveraging a TensorFlow Lite model, we’re able to find 3x more2 phishing sites compared to previous machine learning models and help warn you before you get tricked into signing in. This year, we're expanding the coverage of the model to detect hundreds of more phishing campaigns and leverage new ML technologies.

This is just one example of how we use our AI expertise to keep your data safe. Last year, Android used AI to protect users from 100 billion suspected spam messages and calls.3

Passkeys helps move users beyond passwords

For many, passwords are the primary protection for their online life. In reality, they are frustrating to create, remember and are easily hacked. But cybercriminals can’t phish a password that doesn’t exist. Which is why we are excited to share another major step forward in our passwordless journey: Passkeys.

Passkeys combine the advanced security of 2-Step Verification with the convenience of simply unlocking your device — so signing in is as easy as glancing at your phone or scanning your fingerprint. And because they use cutting-edge cryptography to create a “key” that is unique between you and a specific app or website, passkeys can’t be stolen by hackers the way that passwords can.

Last week, we announced you can use a passkey to log in to your Google Account on all major platforms. We’re the first major tech company to simplify sign-in with passkeys across our own platform. You can also use passkeys on services like PayPal, Shopify, and Docusign, with many more on the way. Start saying goodbye to passwords and try it today.

To help support developers as they incorporate passkeys, we’ve launched a Credential Manager Jetpack API that brings together multiple sign-in methods, such as passkeys, passwords and federated sign in, into a unified interface for users and a single API for developers.

Better protections for apps

Accessibility services are helpful for people with disabilities but their broad powers can be used by malware and bad apps to read screen content. In Android 14, we’re introducing a new API that lets developers limit accessibility services from interacting with their apps. Now, with a new app attribute, developers can limit access to only apps that have declared and have been validated by Google Play Protect as accessibility tools. This adds more protection from side-loaded apps that may get installed and are trying to access sensitive data.

In Android 14, we’re preventing apps that target an SDK level lower than 23 from being installed. This is because malware often targets older levels to get around newer security and privacy protections. This won’t affect existing apps on your device, but new installs will have to meet this requirement.

Learn more about how we’re protecting apps and developers in the What’s New in Google Play blog.

More transparency around how your data is used

We launched the Data safety section in Google Play last year to help you see how developers collect, share, and protect user data. Every day, millions of users use the Data Safety section information to evaluate an app’s safety before installing it.

In Android 14, we’re extending this transparency to permission dialogs, starting with location data usage. So every time an app asks for permission to use location data, you’ll be able to see right away if the app shares the location data with third parties.

And if an app changes its data sharing practices, for example, to start using it for ads purposes, we’ll notify you through a new monthly notification. As with the permissions dialogs, we’re starting with location data but will be expanding to other permission types in future releases.

We’re also empowering you with greater clarity and control over your account data by making it easier to delete accounts that you’ve created in apps. Developers will soon need to provide ways for you to ask for your account and data to be deleted via the app and the app’s Data safety section in Google Play, giving you more control both inside and outside of apps. They can also offer you an option to clean up your account and ask for other data, like activity history or images, to be deleted instead of your entire account.

Better control and protection over your photos and videos

Last year, we announced the Android Photo Picker, a new tool that apps can use to request access to specific photos and videos instead of requesting permission to a users' entire media library. We’re updating Photo Picker through Google Play services to support older devices going back to Android 4.4.

With Android 14, we modified the photo/video permissions to let you choose only specific media to share, even if an app hasn’t opted into Photo Picker. You can still decide to allow or deny all access to photos but this provides more granular control.

We’re also introducing a new API that will enable developers to recognize screenshots without requiring them to get access to your photos. This helps limit media access for developers while still providing them with the tools they need to detect screenshots in their apps.

You can read more about upcoming Android 14 features in the Android 14 beta 2 blog post or read up on the latest Android 14 features on our developer site.

Android remains committed to protecting users by combining advanced security and AI with thoughtful privacy controls and transparency to protect billions of users around the world. Stay tuned for more upcoming protections we’ll be launching throughout the year and learn more about how Android keeps you safe at android.com/safety.

Notes

1. Based on estimated daily increase across desktop and mobile comparing Safe Browsing API 5 to API 4 ↩

2. Based on internal data from January to May 2023." ↩

3. Estimating from annual and monthly spam call and spam messaging data ↩