Category Archives: Online Security Blog

The latest news and insights from Google on security and safety on the Internet

Announcing the winners of the 2020 GCP VRP Prize

Posted by Harshvardhan Sharma, Information Security Engineer, Google 

We first announced the GCP VRP Prize in 2019 to encourage security researchers to focus on the security of Google Cloud Platform (GCP), in turn helping us make GCP more secure for our users, customers, and the internet at large. In the first iteration of the prize, we awarded $100,000 to the winning write-up about a security vulnerability in GCP. We also announced that we would reward the top 6 submissions in 2020 and increased the total prize money to $313,337.

2020 turned out to be an amazing year for the Google Vulnerability Reward Program. We received many high-quality vulnerability reports from our talented and prolific vulnerability researchers.


Vulnerability reports received year-over-year



This trend was reflected in the submissions we received for the GCP VRP Prize. After careful evaluation of the many innovative and high-impact vulnerability write-ups we received this year, we are excited to announce the winners of the 2020 GCP VRP Prize:
  • First Prize, $133,337: Ezequiel Pereira for the report and write-up RCE in Google Cloud Deployment Manager. The bug discovered by Ezequiel allowed him to make requests to internal Google services, authenticated as a privileged service account. Here's a video that gives more details about the bug and the discovery process.

  • Second Prize, $73,331: David Nechuta for the report and write-up 31k$ SSRF in Google Cloud Monitoring led to metadata exposure. David found a Server-side Request Forgery (SSRF) bug in Google Cloud Monitoring's uptime check feature. The bug could have been used to leak the authentication token of the service account used for these checks.
  • Third Prize, $73,331: Dylan Ayrey and Allison Donovan for the report and write-up Fixing a Google Vulnerability. They pointed out issues in the default permissions associated with some of the service accounts used by GCP services.
  • Fourth Prize, $31,337: Bastien Chatelard for the report and write-up Escaping GKE gVisor sandboxing using metadata. Bastien discovered a bug in the GKE gVisor sandbox's network policy implementation due to which the Google Compute Engine metadata API was accessible. 
  • Fifth Prize, $1,001: Brad Geesaman for the report and write-up CVE-2020-15157 "ContainerDrip" Write-up. The bug could allow an attacker to trick containerd into leaking instance metadata by supplying a malicious container image manifest.
  • Sixth Prize, $1,000: Chris Moberly for the report and write-up Privilege Escalation in Google Cloud Platform's OS Login. The report demonstrates how an attacker can use DHCP poisoning to escalate their privileges on a Google Compute Engine VM.
Congratulations to all the winners! If we have peaked your interest and you would like to enter the competition for a GCP VRP Prize in 2021, here’s a reminder on the requirements.
  • Find a vulnerability in a GCP product (check out Google Cloud Free Program to get started)
  • Report it to the VRP (you might get rewarded for it on top of the GCP VRP Prize!)
  • Create a public write-up
  • Submit it here
Make sure to submit your VRP reports and write-ups before December 31, 2021 at 11:59 GMT. Good luck!You can learn more about the prize for this year here. We can't wait to see what our talented vulnerability researchers come up with this year!

Google, HTTPS, and device compatibility

Posted by Ryan Hurst, Product Management, Google Trust Services


Encryption is a fundamental building block when you’re on a mission to organize the world’s information and make it universally accessible with strong security and privacy. This is why a little over four years ago we created Google Trust Services—our publicly trusted Certificate Authority (CA).

The road to becoming a publicly trusted certificate authority is a long one - especially if the certificates you issue will be used by some of the most visited sites on the internet.

When we started on this journey, our goal was that within five years our root certificates would be embedded in enough devices that we could do a single transition to our long-term root certificates.

There are still a large number of active used devices that have not been updated with our root certificates.

To ensure as many clients as possible continue to have secure connections when using Google Trust Services certificates, we needed to obtain a cross-sign. A cross-sign allows a certificate authority that is already trusted by a device to extend its device compatibility to another certificate authority.

The rules governing public CA operations require that the CA being cross-signed meet the same strict operational, technological, and audit criteria as the certificate authority providing this cross-sign. Google Trust Services is already a publicly trusted CA that is operated to the highest standards and is in all major browser trust stores, so we already met the requirements for a cross-sign from another CA.. The key was to find one that is already trusted by the devices we wanted to be able to validate our certificates. We worked with GMO GlobalSign for this cross sign because they operate one of the oldest root certificates in wide use today.

Why are we telling you about this now? On December 15, 2021, the primary root certificate we use today (GlobalSign R2 which is owned and operated by Google Trust Services) will expire.

To ensure these older devices continue to work smoothly with the certificates we issue we will start sending a new cross-signed certificate to services when we issue new certificates.

The good news is that users shouldn’t notice the change. This is because the cross-certificate (GTS Root R1 Cross) we're deploying was signed by a root certificate created and trusted by most devices over 20 years ago.

In summary, when you use certificates from Google Trust Services, you and your customers will continue to get the benefit of the best device compatibility in the industry.

We know you might have some questions about this change. Here are our answers to the most frequent ones:

I am a developer or ISV that uses a Google API. What do I need to do?

Certificate Authorities change which root CA certificates they use from time to time, so we have always provided a list of certificates that we currently use or may use in the future. Anybody using this list won’t have to change anything. If you have not been using this list and updating it based on our published guidance, you will need to update your application to use these roots and regularly update the list you use so future changes go smoothly for your users.

I am a website operator that uses Google Trust Services certificates. Do I need to change anything?

You do not! Google Trust Services offers certificates to Alphabet products and services including many Google Cloud services. This means that those services are the ones responsible for configuring and managing TLS for you.

When will this change go into effect? 

We will begin rolling out certificate chains that use this cross-certificate in March 2021. We will slowly roll these changes out throughout the rest of the year and will complete them before December 15, 2021.

I use a service or product that uses Google Trust Services. Is there anything I need to change? No, this change should be invisible to all end users.

How can I test to see if my devices will trust certificates that rely on this cross-sign? 

We operate a test site that uses the cross-certificate that you can visit here. If you see "Google Trust Services Demo Page - Expected Status: good" and some additional certificate information, the new certificate chain works correctly on your device. If you get an error, the list of trusted roots for the device you're testing needs to be updated.

When does this cross-certificate expire and what happens when it does? 

The cross-certificate expires January 28th, 2028. Sometime between now and when it looks like it is no longer needed for broad device compatibility, we will stop providing this extra certificate to certificate requesters, as it will no longer be needed.

I use an old device and it does not trust the cross-sign. What should I do? 

Many devices handle root certificate updates as part of their security patching process. If you are running one of these devices, you should make sure you apply all relevant security updates. It is also possible the manufacturer no longer provides security updates for your device. If this is the case you may want to contact your provider or consider replacing your device.

Does this mean you are no longer using the Google Trust Services roots? We are still using the Google Trust Services roots, they are simply cross-signed. When it is no longer necessary to use the cross-sign, we will no longer distribute the cross-sign to certificate requestors.

To learn more, visit Google Trust Services.

A Spectre proof-of-concept for a Spectre-proof web

Posted by Stephen Röttger and Artur Janc, Information Security Engineers


Three years ago, Spectre changed the way we think about security boundaries on the web. It quickly became clear that flaws in modern processors undermined the guarantees that web browsers could make about preventing data leaks between applications. As a result, web browser vendors have been continuously collaborating on approaches intended to harden the platform at scale. Nevertheless, this class of attacks still remains a concern and requires web developers to deploy application-level mitigations.


In this post, we will share the results of Google Security Team's research on the exploitability of Spectre against web users, and present a fast, versatile proof-of-concept (PoC) written in JavaScript which can leak information from the browser's memory. We've confirmed that this proof-of-concept, or its variants, function across a variety of operating systems, processor architectures, and hardware generations.


By sharing our findings with the security community, we aim to give web application owners a better understanding of the impact Spectre vulnerabilities can have on the security of their users' data. Finally, this post describes the protections available to web authors and best practices for enabling them in web applications, based on our experience across Google.


A bit of background


The Spectre vulnerability, disclosed to the public in January 2018, makes use of a class of processor (CPU) design vulnerabilities that allow an attacker to change the intended program control flow while the CPU is speculatively executing subsequent instructions. For example, the CPU may speculate that a length check passes, while in practice it will access out-of-bounds memory. While the CPU state is rolled back once the misprediction is noticed, this behavior leaves observable side effects which can leak data to an attacker.


In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation. 


In parallel, browser vendors and standards bodies developed security mechanisms to protect web users from these classes of attacks. This included both architectural changes which offer default protections enabled in some browser configurations (such as Site Isolation, out-of-process iframes, and Cross-Origin Read Blocking), as well as broadly applicable opt-in security features that web developers can deploy in their applications: Cross-Origin Resource Policy, Cross-Origin Opener Policy, Cross-Origin Embedder Policy, and others.


These mechanisms, while crucially important, don't prevent the exploitation of Spectre; rather, they protect sensitive data from being present in parts of the memory from which they can be read by the attacker. To evaluate the robustness of these defenses, it's therefore important to develop security tools that help security engineers understand the practical implications of speculative execution attacks for their applications.


Demonstrating Spectre in a web browser


Today, we’re sharing proof-of-concept (PoC) code that confirms the practicality of Spectre exploits against JavaScript engines. We use Google Chrome to demonstrate our attack, but these issues are not specific to Chrome, and we expect that other modern browsers are similarly vulnerable to this exploitation vector. We have developed an interactive demonstration of the attack available at https://leaky.page/; the code and a more detailed writeup are published on Github here.




The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.


While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.

  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.


We chose to release the current PoC since it has a negligible setup time and works in the absence of high precision timers, such as SharedArrayBuffer.


The main building blocks of the PoC are:

  1. A Spectre gadget: code that triggers attacker-controlled transient execution.

  2. A side-channel: a way to observe side effects of the transient execution.


1. The gadget

For the published PoC, we implemented a simple Variant 1 gadget: a JavaScript array is speculatively accessed out of bounds after training the branch predictor that the compiler-inserted length check will succeed. This particular gadget can be mitigated at the software level; however, Chrome's V8 team concluded that this is not the case for other gadgets: “we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software.”


We invite the security community to extend our research and develop code that makes use of other Spectre gadgets.


2. The side-channel

A common way to leak secret data via speculative execution is to use a cache side-channel. By observing if a certain memory location is present in the cache or not, we can infer if it has been accessed during the speculative execution. The challenge in JavaScript is to find a high resolution timer allowing to distinguish cache from memory accesses, as modern browsers have reduced the timer granularity of the performance.now() API and disabled SharedArrayBuffers in contexts without cross-origin isolation to prevent timing attacks.


Already in 2018, the V8 team shared their observation that reduced timer granularity is not sufficient to mitigate Spectre, since attackers can arbitrarily amplify timing differences. The presented amplification technique was based on reading secret data multiple times which can, however, reduce the effectiveness of the attack if the information leak is probabilistic.


In our PoC, we developed a new technique that overcomes this limitation. By abusing the behavior of the Tree-PLRU cache eviction strategy commonly found in modern CPUs, we were able to significantly amplify the cache timing with a single read of secret data. This allowed us to leak data efficiently even with low precision timers. For technical details, see the demonstration at https://leaky.page/plru.html.


While we don't believe this particular PoC can be re-used for nefarious purposes without significant modifications, it serves as a compelling demonstration of the risks of Spectre. In particular, we hope it provides a clear signal for web application developers that they need to consider this risk in their security evaluations and take active steps to protect their sites.


Deploying web defenses against Spectre


The low-level nature of speculative execution vulnerabilities makes them difficult to fix comprehensively, as a proper patch can require changes to the firmware or hardware on the user's device. While operating system and web browser developers have implemented important built-in protections where possible (including Site Isolation with out-of-process iframes and Cross-Origin Read Blocking in Google Chrome, or Project Fission in Firefox), the design of existing web APIs still makes it possible for data to inadvertently flow into an attacker's process.


With this in mind, web developers should consider more robustly isolating their sites by using new security mechanisms that actively deny attackers access to cross-origin resources. These protections mitigate Spectre-style hardware attacks and common web-level cross-site leaks, but require developers to assess the threat these vulnerabilities pose to their applications and understand how to deploy them. To assist in that evaluation, Chrome's web platform security team has published Post-Spectre Web Development and Mitigating Side-Channel Attacks with concrete advice for developers; we strongly recommend following their guidance and enabling the following protections:



  • Cross-Origin Opener Policy (COOP) lets developers ensure that their application window will not receive unexpected interactions from other websites, allowing the browser to isolate it in its own process. This adds an important process-level protection, particularly in browsers which don't enable full Site Isolation; see web.dev/coop-coep.


  • Cross-Origin Embedder Policy (COEP) ensures that any authenticated resources requested by the application have explicitly opted in to being loaded.  Today, to guarantee process-level isolation for highly sensitive applications in Chrome or Firefox, applications must enable both COEP and COOP; see web.dev/coop-coep.


In addition to enabling these isolation mechanisms, ensure your application also enables standard protections, such as the X-Frame-Options and X-Content-Type-Options headers, and uses SameSite cookies. Many Google applications have already deployed, or are in the process of deploying these mechanisms, providing a defense against speculative execution bugs in situations where default browser protections are insufficient. 


It's important to note that while all of the mechanisms described in this article are important and powerful security primitives, they don't guarantee complete protection against Spectre; they require a considered deployment approach which takes behaviors specific to the given application into account. We encourage security engineers and researchers to use and contribute to our Spectre proof-of-concept to review and improve the security posture of their sites.



Tip: To help you protect your website from Spectre, the Google Security Team has created Spectroscope, a prototype Chrome extension that scans your application and finds resources which may require enabling additional defenses. Consider using it to assist with your deployments of web isolation features.

Continuing to Raise the Bar for Verifiable Security on Pixel

Posted by Eugene Liderman, Android Security and Privacy Team

Evaluating the security of mobile devices is difficult, and a trusted way to validate a company’s claims is through independent, industry certifications. When it comes to smartphones one of the most rigorous end-to-end certifications is the Common Criteria (CC) Mobile Device Fundamentals (MDF) Protection Profile. Common Criteria is the driving force for establishing widespread mutual recognition of secure IT products across 31 countries . Over the past few years only three smartphone manufacturers have continually been certified on every OS version: Google, Samsung, and Apple. At the beginning of February, we successfully completed this certification for all currently supported Pixel smartphones running Android 11. Google is the first manufacturer to be certified on the latest OS version.

This specific certification is designed to evaluate how a device defends against the real-world threats facing both consumers and businesses. The table below outlines the threats and mitigations provided in the CC MDF protection profile:

This specific certification is designed to evaluate how a device defends against the real-world threats facing both consumers and businesses. The table below outlines the threats and mitigations provided in the CC MDF protection profile:

Threats

Mitigations

Network Eavesdropping - An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure

Network Attack - An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure

Protected Communications - Standard protocols such as IPsec, DTLS, TLS, HTTPS, and Bluetooth to ensure encrypted communications are secure

Authorization and Authentication - Secure authentication for networks and backends

Mobile Device Configuration - Capabilities for configuring and applying security policies defined by the user and/or Enterprise Administrator

Physical Access - An attacker, with physical access, may attempt to retrieve user data on the mobile device, including credentials

Protected Storage - Secure storage (that is, encryption of data-at-rest) for data contained on the device 

Authorization and Authentication - Secure device authentication using a known unlock factor, such as a password, PIN, fingerprint, or face authentication

Malicious or Flawed Application - Applications loaded onto the Mobile Device may include malicious or exploitable code 

Protected Communications - Standard protocols such as IPsec, DTLS, TLS, HTTPS, and Bluetooth to ensure encrypted communications are secure

Authorization and Authentication - Secure authentication for networks and backends

Mobile Device Configuration - Capabilities for configuring and applying security policies defined by the user and/or Enterprise Administrator

Mobile Device Integrity - Device integrity for critical functionality of both software and hardware

End User Privacy and Device Functionality - Application isolation/sandboxing and framework permissions provide separation and privacy between user activities

Persistent Presence - Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it 

Mobile Device Integrity - Device integrity to ensure the integrity of critical functionality of both software and hardware is maintained

End User Privacy and Device Functionality - Application isolation/sandboxing and framework permissions provide separation and privacy between user activities


What makes this certification important is the fact that it is a hands on evaluation done by an authorized lab to evaluate the device and perform a variety of tests to ensure that:

  1. Every mitigation meets a predefined standard and set of criteria.
  2. Every mitigation works as advertised.

At a high level, the target of evaluation (TOE) is the combination of device hardware (i.e. system on chip) and operating system (i.e. Android). In order to validate our mitigations for the threats listed above, the lab looks at the following security functionality:

  • Protected Communications (encryption of data-in-transit) - Cryptographic algorithms and transport protocols used to encrypt the Wi-Fi traffic and all other network operations and communications.
  • Protected Storage (encryption of data-at-rest) - Cryptography provided by the system on chip, trusted execution environment, and any other discrete tamper resistant hardware such as the Titan M and the Android OS. Specifically looking at things like implementation of file-based encryption, hardware root of trust, keystore operations (such as, key generation), key storage, key destruction, and key hierarchy.
  • Authorization and Authentication - Mechanisms for unlocking the user’s devices, such as password, PIN or Biometric. Mitigation techniques like rate limiting and for biometrics, False Acceptance and Spoof Acceptance Rates.
  • Mobile Device Integrity - Android’s implementation of Verified Boot, Google Play System Updates, and Seamless OS Updates.
  • Auditability - Features that allow a user or IT admin to log events such as device start-up and shutdown, data encryption, data decryption, and key management.
  • Mobile Device Configuration - Capabilities that allow the user or enterprise admin to apply security policies to the device using Android Enterprise.

Why this is important for enterprises

It’s incredibly important to ensure Pixel security can specifically support enterprise needs. Many regulated industries require the use of Common Criteria certified devices to ensure that sensitive data is backed by the strongest possible protections. The Android Enterprise management framework enables enterprises to do things like control devices by setting restrictions around what the end user can do and audit devices to ensure all software settings are configured properly. For example, enterprise IT admins wish to enforce policies for features like the camera, location services or app installation process.

Why this is important for consumers

Security isn’t just an enterprise concern and many of the protections validated by Common Criteria certification apply to consumers as well. For example, when you’re connecting to Wi-Fi, you want to ensure no one can spy on your web browsing. If your device is lost or stolen, you want to be confident that your lock screen can reduce the chances of someone accessing your personal information.

We believe in making security & privacy accessible to all of our users. This is why we take care to ensure that Pixel devices meet or exceed these certification standards.. We’re committed to meeting these standards moving forward, so you can rest assured that your Pixel phone comes with top-of-the-line security built in, from the moment you turn it on.

Why this is important to the Android Ecosystem

While certifications are a great form of third party validation, they often fall under what we like to call the 3 C’s:

  • Complex - Due to the scope of the evaluation including the device hardware, the operating system and everything in between.
  • Costly - Because they require a hands on evaluation by a certified lab for every make/model combination (SoC + OS) which equates to hundreds of individual tests.
  • Cumbersome - Because it’s a fairly lengthy evaluation process that can take upwards of 18 months the first time you go through it.

We have been working these last three years to reduce this complexity for our OEM partners. We are excited to tell you that the features required to satisfy the necessary security requirements are baked directly into the Android Open Source Project. We’ve also added all of the management and auditability requirements into the Android Enterprise Management framework. Last year we started publishing the tools we have developed for this on GitHub to allow other Android OEMs to take advantage of our efforts as they go through their certification.

While we continue certifying Pixel smartphones with new Android OS versions, we have worked to enable other Android OEMs to achieve this certification as well as others, such as:

  • National Institute of Technology’s Cryptographic Algorithm and Module Validation Programs which is an evaluation of the cryptographic algorithms and/or modules and is something the US Public Sector and numerous other regulated verticals look for. With Android 11, BoringSSL which is part of the conscrypt mainline module has completed this validation (Certificate #3753)
  • US Department of Defense's Security Technical Implementation Guide; STIG for short is a guideline for how to deploy technology on a US Department of Defense network. In the past there were different STIGs for different Android OEMs which had their own implementations and proprietary controls, but thanks to our efforts we are now unifying this under a single Android STIG template so that Android OEMs don’t have to go through the burden of building custom controls to satisfy the various requirements.

We’ll continue to invest in additional ways to measure security for both enterprises and consumers, and we welcome the industry to join us in this effort.

#ShareTheMicInCyber: Brooke Pearson

Posted by Parisa Tabriz, Head of Chrome Product, Engineering and UX 

In an effort to showcase the breadth and depth of Black+ contributions to security and privacy fields, we’ve launched a profile series that aims to elevate and celebrate the Black+ voices in security and privacy we have here at Google.



Brooke Pearson manages the Privacy Sandbox program at Google, and her team's mission is to, “Create a thriving web ecosystem that is respectful of users and private by default.” Brooke lives this mission and it is what makes her an invaluable asset to the Chrome team and Google. 

In addition to her work advancing the fields of security and privacy, she is a fierce advocate for women in the workplace and for elevating the voices of her fellow Black+ practitioners in security and privacy. She has participated and supported the #ShareTheMicInCyber campaign since its inception.

Brooke is passionate about delivering privacy solutions that work and making browsing the web an inherently more private experience for users around the world.



Why do you work in security or privacy?

I work in security and privacy to protect people and their personal information. It’s that simple. Security and privacy are two issues that are core to shaping the future of technology and how we interact with each other over the Internet. The challenges are immense, and yet the ability to impact positive change is what drew me to the field.

Tell us a little bit about your career journey to Google

My career journey into privacy does not involve traditional educational training in the field. In fact, my background is in public policy and communications, but when I transitioned to the technology industry, I realized that the most pressing policy issues for companies like Google surround the nascent field of privacy and the growing field of security.

After I graduated from college at Azusa Pacific University, I was the recipient of a Fulbright scholarship to Macau, where I spent one year studying Chinese and teaching English. I then moved to Washington D.C. where I initially worked for the State Department while finishing my graduate degree in International Public Policy at George Washington University. I had an amazing experience in that role and it afforded me some incredible networking opportunities and the chance to travel the world, as I worked in Afghanistan and Central Asia.

After about five years in the public sector, I joined Facebook as a Program Manager for the Global Public Policy team, initially focused on social good programs like Safety Check and Charitable Giving. Over time, I could see that the security team at Facebook was focused on fighting the proliferation of misinformation, and this called to me as an area where I could put my expertise in communication and geopolitical policy to work. So I switched teams and I've been in the security and privacy field ever since, eventually for Uber and now with Google's Chrome team.

At Google, privacy and security are at the heart of everything we do. Chrome is tackling some of the world's biggest security and privacy problems, and everyday my work impacts billions of people around the world. Most days, that's pretty daunting, but every day it's humbling and inspiring.

What is your security or privacy "soapbox"?

If we want to encourage people to engage in more secure behavior, we have to make it easy to understand and easy to act on. Every day we strive to make our users safer with Google by implementing security and privacy controls that are effective and easy for our users to use and understand.

As a program manager, I’ve learned that it is almost always more effective to offer a carrot than a stick, when it comes to security and privacy hygiene. I encourage all of our users to visit our Safety Center to learn all the ways Google helps you stay safe online, every day.

If you are interested in following Brooke’s work here at Google and beyond, please follow her on Twitter @brookelenet. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network.

If you are interested in participating or learning more about #ShareTheMicInCyber, click here.

Fuzzing Java in OSS-Fuzz

Posted by Jonathan Metzman, Google Open Source Security Team

OSS-Fuzz, Google’s open source fuzzing service, now supports fuzzing applications written in Java and other Java Virtual Machine (JVM) based languages (e.g. Kotlin, Scala, etc.). Open source projects written in JVM based languages can add their project to OSS-Fuzz by following our documentation.

The Google Open Source Security team partnered with Code Intelligence to integrate their Jazzer fuzzer with OSS-Fuzz. Thanks to their integration, open source projects written in JVM-based languages can now use OSS-Fuzz for continuous fuzzing.

OSS-Fuzz has found more than 25,000 bugs in open source projects using fuzzing. We look forward to seeing how this technique can help secure and improve code written in JVM-based languages.

What can Jazzer do?

Jazzer allows users to fuzz code written in JVM-based languages with libFuzzer, as they already can for code written in C/C++. It does this by providing code coverage feedback from JVM bytecode to libFuzzer. Jazzer already supports important libFuzzer features such as:

  • FuzzedDataProvider for fuzzing code that doesn’t accept an array of bytes.
  • Evaluation of code coverage based on 8-bit edge counters.
  • Value profile.
  • Minimization of crashing inputs.
The intent for Jazzer is to support all libFuzzer features eventually.

What Does Jazzer Support?

Jazzer supports all languages that compile to JVM bytecode, since instrumentation is done on the bytecode level. This includes:
  • Java
  • Kotlin
  • Scala
  • Clojure
Jazzer can also provide coverage feedback from native code that is executed through JNI. This can uncover interesting memory corruption vulnerabilities in memory unsafe native code.

Why Fuzz Java/JVM-based Code?

As discussed in our post on Atheris, fuzzing code written in memory safe languages, such as JVM-based languages, is useful for finding bugs where code behaves incorrectly or crashes. Incorrect behavior can be just as dangerous as memory corruption. For example, Jazzer was used to find CVE-2021-23899 in json-sanitizer which could be exploited for cross-site scripting (XSS). Bugs causing crashes or incorrect exceptions can sometimes be used for denial of service. For example, OSS-Fuzz recently found a denial of service issue that could have been used to take “a major part of the ethereum network offline”.

When fuzzing memory safe code, you can use the same classic approach for fuzzing memory unsafe code: passing mutated input to code and waiting for crashes. Or you can take a more unit test like approach where your fuzzer verifies that the code is behaving correctly (example).

Another way fuzzing can find interesting bugs in JVM-based code is through differential fuzzing. With differential fuzzing, your fuzzer passes mutated input from the fuzzer to multiple library implementations that should have the same functionality. Then it compares the results from each library to find differences.
Check out our documentation to get started. We will explore this more during our OSS-Fuzz talk at FuzzCon Europe.

Introducing sigstore: Easy Code Signing & Verification for Supply Chain Integrity

Posted by Kim Lewandowski & Dan Lorenc, Google Open Source Security Team

One of the fundamental security issues with open source is that it’s difficult to know where the software comes from or how it was built, making it susceptible to supply chain attacks. A few recent examples of this include dependency confusion attack and malicious RubyGems package to steal cryptocurrency.

Today we welcome the announcement of sigstore, a new project in the Linux Foundation that aims to solve this issue by improving software supply chain integrity and verification.

Installing most open source software today is equivalent to picking up a random thumb-drive off the sidewalk and plugging it into your machine. To address this we need to make it possible to verify the provenance of all software - including open source packages. We talked about the importance of this in our recent Know, Prevent, Fix post.

The mission of sigstore is to make it easy for developers to sign releases and for users to verify them. You can think of it like Let’s Encrypt for Code Signing. Just like how Let’s Encrypt provides free certificates and automation tooling for HTTPS, sigstore provides free certificates and tooling to automate and verify signatures of source code. Sigstore also has the added benefit of being backed by transparency logs, which means that all the certificates and attestations are globally visible, discoverable and auditable.

Sigstore is designed with open source maintainers, for open source maintainers. We understand long-term key management is hard, so we've taken a unique approach of issuing short-lived certificates based on OpenID Connect grants. Sigstore also stores all activity in Transparency Logs, backed by Trillian so that we can more easily detect compromises and recover from them when they do occur. Key distribution is notoriously difficult, so we've designed away the need for them by building a special Root CA just for code signing, which will be made available for free.

We have a working prototype and proof of concepts that we're excited to share for feedback. Our goal is to make it seamless and easy to sign and verify code:


It has been fun collaborating with the folks from Red Hat and the open source community on this project. Luke Hinds, one of the lead developers on sigstore and Security Engineering Lead at Red Hat says, "I am very excited about sigstore and what this means for improving the security of software supply chains. sigstore is an excellent example of an open source community coming together to collaborate and develop a solution to ease the adoption of software signing in a transparent manner." We couldn’t agree more.

Mike Malone, the CEO of Smallstep, helped with the overall design of sigstore. He adds, “In less than a generation, open source has grown from a niche community to a critical ecosystem that powers our global economy and institutions of society and culture. We must ensure the security of this ecosystem without undermining the open, decentralized collaboration that makes it work. By building on a clever composition of existing technologies that respect privacy and work at scale, sigstore is the core infrastructure we need to solve this fundamental problem. It’s an ambitious project with potential for global impact. I’m impressed by the rapid progress that’s been made by Google, Red Hat, and Linux Foundation over the past few months, and I’m excited to hear feedback from the broader community.”

While we are happy with the progress that has been made, we know there is still work to be done before this can be widely relied upon. Upcoming plans for sigstore include: hardening the system, adding support for other OpenID Connect providers, updating documentation and responding to community feedback.

Sigstore is in its early days, but we're really excited about its future. Now is a great time to provide feedback, try out the tooling and get involved with the project as design details are still being refined.

#ShareTheMicInCyber: Rob Duhart

Posted by Matt Levine, Director, Risk Management

In an effort to showcase the breadth and depth of Black+ contributions to security and privacy fields, we’ve launched a series in support of #ShareTheMicInCyber that aims to elevate and celebrate the Black+ voices in security and privacy we have here at Google.

Today, we will hear from Rob Duhart, he leads a cross functional team at Google that aims to enable and empower all of our products, like Chrome, Android and Maps, to mature their security risk journey.

Rob’s commitment to making the internet a safer place extends far beyond his work at Google, he is a member of the Cyber Security Executive Education Advisory Board of Directors at Washington University in St. Louis, where he helps craft the future of cyber security executive education globally. Rob also sits on the board of the EC-Council and has founded chapters of the International Consortium of Cybersecurity Professionals (ICMCP) across the country.

Rob is passionate about securing the digital world and supporting Black+, women, and underrepresented minorities across the technology landscape.


Why do you work in security or privacy?

I have been in the cyber world long enough to know how important it is for security and privacy to be top of mind and focus for organizations of all shapes and sizes. My passion lies in keeping users and Googlers safe. One of the main reasons I joined Google is its commitment to security and privacy.


Tell us a little bit about your career journey to Google...

I was fortunate to begin my cybersecurity career in the United States Government working at the Department of Energy, FBI, and the Intelligence Community. I transitioned to the private sector in 2017 and have been fortunate to lead talented security teams at Cardinal Health and Ford Motor Company.

My journey into cybersecurity was not traditional. I studied Political Science at Washington University in St. Louis, completed graduate education at George Mason University and Carnegie Mellon University. I honed my skills and expertise in this space through hands on experience and with the support of many amazing mentors. It has been the ride of a lifetime and I look forward to what is next.

To those thinking about making a career change or are just starting to get into security, my advice is don’t be afraid to ask for help.


What is your security or privacy "soapbox"?

At Google, we implement a model known as Federated Security, where our security teams partner across our Product Areas to enable security program maturity Google wide. Our Federated Security team believes in harnessing the power of relationship, engagement, and community to drive maturity into every product. Security and privacy are team sports – it takes business leaders and security leaders working together to secure and protect our digital and physical worlds.

If you are interested in following Rob’s work here at Google and beyond, please follow him on Twitter @RobDuhart. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network.

If you are interested in participating or learning more about #ShareTheMicInCyber, click here.

Celebrating the influence and contributions of Black+ Security & Privacy Googlers

Posted by Royal Hansen, Vice President, Security

Black History Month may be coming to a close, but our work to build sustainable equity for Google’s Black+ community, and externally is ongoing. Currently, Black Americans make up less than 12% of information security analysts in the U.S. In an industry that consistently requires new ideas to spark positive change and stand out against the status quo, it is necessary to have individuals who think, speak, and act in diverse ways. Diverse security teams are more innovative, produce better products and enhance an organization's ability to defend against cyber threats.

In an effort to amplify the contributions of the Black+ community to security and privacy fields, we’ll be sharing profiles of Black+ Googlers working on innovative privacy and security solutions over the coming weeks, starting with Camille Stewart, Google’s Head of Security Policy for Google Play and Android.

Camille co-founded #ShareTheMicInCyber, an initiative that pairs Black security practitioners with prominent allies, lending their social media platforms to the practitioners for the day. The goal is to break down barriers, engage the security community, and promote sustained action. The #ShareTheMicInCyber campaign will highlight Black women in the security and privacy sector on LinkedIn and Twitter on March 19, 2021 and throughout March 2021 in celebration of Women's History Month. Follow the #ShareTheMicInCyber on March 19th to support and amplify Black women in security and privacy.

Read more about Camille’s story below ↓

#ShareTheMicInCyber: Camille Stewart

Today, we will hear from Camille Stewart, she leads security, privacy, election integrity, and dis/misinformation policy efforts for Google's mobile business. She also spearheads a cross-Google security initiative that sets the strategic vision and objectives for Google’s engagement on security and privacy issues.

In her (not so) spare time, Camille is co-founder of the #ShareTheMicInCyber initiative – which aims to elevate the profiles, work, and lived experiences of Black cyber practitioners. This initiative has garnered national and international attention and has been a force for educating and bringing awareness to the challenges Black security practitioners face in industry. Camille is also a cybersecurity fellow at Harvard University, New America and Truman National Security Project. She sits on the board of the International Foundation for Electoral Systems and of Girl Security, an organization that is working to close the gender gap in national security through learning, training, and mentoring support for girls.





Why do you work in security or privacy?

I work in this space to empower people in and through technology by translating and solving the complex challenges that lie at the intersection of technology, security, society, and the law.

Tell us a little bit about your career journey to Google

Before life at Google, I managed cybersecurity, election security, tech innovation, and risk issues at Deloitte. Prior to that, I was appointed by President Barack Obama to be the Senior Policy Advisor for Cyber Infrastructure & Resilience Policy at the Department of Homeland Security. I was the Senior Manager of Legal Affairs at Cyveillance, a cybersecurity company after working on Capitol Hill.

What is your security or privacy "soapbox"?

Right now, I have a few. Users being intentional about their digital security similar to their physical security especially with their mobile devices and apps. As creators of technology, we need to be more intentional about how we educate our users on safety and security. At Google, security is core to everything we do and build, it has to be. We recently launched our Safer With Google campaign which I believe is a great resource for helping users better understand their security and privacy journey.

As an industry, we need to make meaningful national and international progress on digital supply chain transparency and security.

Lastly, the fact that systemic racism is a cybersecurity threat. I recently penned a piece for the Council on Foreign Relations that explores how racism influences cybersecurity and what we must do as an industry to address it.

If you are interested in following Camille’s work here at Google and beyond, please follow her on Twitter @CamilleEsq. We will be bringing you more profiles over the coming weeks and we hope you will engage with and share these with your network. 

If you are interested in participating or learning more about #ShareTheMicInCyber, click here.

New Password Checkup Feature Coming to Android

Posted by Arvind Kumar Sugumar, Software Engineer, Android Team

With the proliferation of digital services in our lives, it’s more important than ever to make sure our online information remains safe and secure. Passwords are usually the first line of defense against hackers, and with the number of data breaches that could publicly expose those passwords, users must be vigilant about safeguarding their credentials.

To make this easier, Chrome introduced the Password Checkup feature in 2019, which notifies you when one of the passwords you’ve saved in Chrome is exposed. We’re now bringing this functionality to your Android apps through Autofill with Google. Whenever you fill or save credentials into an app, we’ll check those credentials against a list of known compromised credentials and alert you if your password has been compromised. The prompt can also take you to your Password Manager page, where you can do a comprehensive review of your saved passwords. Password Checkup on Android apps is available on Android 9 and above, for users of Autofill with Google.

Follow the instructions below to enable Autofill with Google on your Android device:

  1. Open your phone’s Settings app
  2. Tap System > Languages & input > Advanced
  3. Tap Autofill service
  4. Tap Google to make sure the setting is enabled

If you can’t find these options, check out this page with details on how to get information from your device manufacturer.

How it works

User privacy is top of mind, especially when it comes to features that handle sensitive data such as passwords. Autofill with Google is built on the Android autofill framework which enforces strict privacy & security invariants that ensure that we have access to the user’s credentials only in the following two cases: 1) the user has already saved said credential to their Google account; 2) the user was offered to save a new credential by the Android OS and chose to save it to their account.

When the user interacts with a credential by either filling it into a form or saving it for the first time, we use the same privacy preserving API that powers the feature in Chrome to check if the credential is part of the list of known compromised passwords tracked by Google.

This implementation ensures that:

  • Only an encrypted hash of the credential leaves the device (the first two bytes of the hash are sent unencrypted to partition the database)
  • The server returns a list of encrypted hashes of known breached credentials that share the same prefix
  • The actual determination of whether the credential has been breached happens locally on the user’s device
  • The server (Google) does not have access to the unencrypted hash of the user’s password and the client (User) does not have access to the list of unencrypted hashes of potentially breached credentials

For more information on how this API is built under the hood, check out this blog from the Chrome team.

Additional security features

In addition to Password Checkup, Autofill with Google offers other features to help you keep your data secure:

  • Password generation: With so many credentials to manage, it’s easy for users to recycle the same password across multiple accounts. With password generation, we’ll generate a unique, secure password for you and save it to your Google account so you don’t have to remember it at all. On Android, you can request password generation for an app by long pressing the password field and selecting “Autofill” in the pop-up menu.
  • Biometric authentication: You can add an extra layer of protection on your device by requiring biometric authentication any time you autofill your credentials or payment information. Biometric authentication can be enabled inside of the Autofill with Google settings.

As always, stay tuned to the Google Security blog to keep up to date on the latest ways we’re improving security across our products.