Product Status: Microarchitectural Data Sampling (MDS)

Overview

This document lists affected Google products and their current status of mitigation against the CPU side channel issues known as Microarchitectural Data Sampling (MDS), described in CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091.

The issue has been mitigated in many Google products (or wasn’t an issue in the first place). In some instances users and customers may need to take additional steps to ensure they’re using a protected version of a product, as detailed below.

This list and a product’s status may change as new developments warrant.

Google Products and Services

Product	User Action Required?
Google Infrastructure The infrastructure that runs Google products (e.g., Search, YouTube, Google Ads products, Maps, Blogger, and other services) and stores customer data is protected against known attacks.	No additional user or customer action needed.
Android The vast majority of Android devices are not affected, as these issues are limited to some Intel-based systems.	For systems that do not use Intel processors, no additional user or customer action is required. For systems running Android on Intel-based Chrome OS devices, updates are handled by Chrome OS (see below). For Intel-based systems that are not Chrome OS devices, users should contact their device manufacturer for available updates.
Google Apps / G Suite The infrastructure that runs G Suite (e.g., Gmail, Calendar, Drive, Docs, and other G Suite services) is protected against known attacks.	No additional user or customer action needed.
Google Cloud Platform See Google Cloud Platform Products and Services, below.	Some GCP products require user action.  See Google Cloud Platform Products and Services below.
Google Chrome Browser Chrome Browser relies on mitigations provided by the operating system on which it runs.	Chrome users should follow guidance from their operating system vendor in relation to MDS mitigation, and ensure they keep Chrome up to date. For more details, please see Chrome’s response.
Google Chrome OS (Chromebooks, etc.) Google has disabled Hyper-Threading by default on Chrome OS 74 and later. Chrome OS 75 will include additional mitigations.	No additional user or customer action is needed. Users wishing to control Hyper-Threading directly should refer to these instructions.
Google Search Appliance Google Search Appliance runs only trusted code from Google and is not at risk.	No additional user or customer action needed.
Google Wifi / OnHub Google Wifi and OnHub run only trusted code from Google and are not at risk.	No additional user or customer action needed.

 

Google Cloud Platform Products and Services

Product	User Action Required?
Google Cloud Infrastructure The infrastructure that runs Google Cloud and isolates customer workloads from each other is protected against known attacks.	No additional user or customer action needed to protect Google Cloud's infrastructure. For some Cloud products, customers may need to patch their runtime environments; see product-specific entries below for guidance.
Google App Engine Standard Environment, Cloud Run, Cloud Functions The infrastructure that runs Google App Engine Standard, Cloud Run, and Cloud Functions and isolates customer workloads from each other is protected against known attacks.	No additional user or customer action needed.
Google App Engine Flexible Environments The infrastructure that runs Google App Engine Flexible Environments and isolates customer workloads from each other is protected against known attacks.	No additional user or customer action is needed. Customers should review Intel best practices with respect to application-level sharing which may occur between hyperthreads within a Flex VM.
Google Cloud Composer The infrastructure that runs Google Cloud Composer and isolates customer workloads from each other is protected against known attacks. Cloud Composer customers who run additional untrusted software on the GKE Clusters managed by Cloud Composer may be vulnerable. In this environment, it may be possible for a malicious binary to observe the microarchitectural data of the other containers running on the same GKE Node. Google will automatically start patching all Cloud Composer GKE Clusters starting the week of May 20th.	For most Cloud Composer customers, no additional action is needed. Cloud Composer customers who run multiple untrusted workloads on the Compute Engine VM, or are otherwise concerned about intra-guest exfiltration, should disable hyperthreading.  In this case, customers should also consider immediately manually upgrading their Composer GKE Clusters when updates become available the week of May 20th rather than waiting for the next scheduled automatic update.
Google Cloud Dataflow The infrastructure that runs Google Cloud Dataflow and isolates customer workloads from each other is protected against known attacks. Cloud Dataflow customers who run additional untrusted software on the Compute Engine VMs managed by Dataflow may be vulnerable. In this environment, it may be possible for a malicious binary to observe the microarchitectural data of the other processes running on the same VM.	For most Cloud Dataflow customers, no additional action is needed. Dataflow customers who run multiple untrusted workloads on the Compute Engine VM managed by Dataflow, or are otherwise concerned about intra-guest attacks, should disable hyperthreading. In this case, customers should also consider updating any streaming pipelines that were launched before the patched image is available and are currently running, and restart any batch pipelines that were launched before the patched image is available. Pipelines launched after the patched image available will automatically have the patch. In cases where updating the streaming pipelines is not possible, Cloud Dataflow customers can drain the pipelines and restart them. The Cloud Dataflow worker VM image will be updated to the patched version when it becomes available. Customers should subscribe to Dataflow release notes to get notified when patched images are available.
Google Cloud Dataproc The infrastructure that runs Google Cloud Dataproc clusters and isolates customer workloads from each other is protected against known attacks. Cloud Dataproc customers who run multiple, untrusted workloads on the same Cloud Dataproc cluster are vulnerable. In this environment, it may be possible for a malicious workload to observe the microarchitectural data of the other workloads running on the same VM or for the malicious workload to observe the memory of the guest operating system.	For most Cloud Dataproc customers, no additional action is needed.   Cloud Dataproc customers who run multiple, untrusted workloads on the same Cloud Dataproc cluster , or are otherwise concerned about intra-guest attacks, should disable hyperthreading on shared clusters. In this case, customers should also consider updating their Dataproc clusters when updated images become available. For customers who deploy ephemeral Dataproc clusters on-demand, using the default latest image or specifying a <major>.<minor> image version, new cluster deployments will automatically use the newest patched images as soon as they become available, and no additional customer action is needed. Customers who have long-lived Dataproc clusters or pin to a specific <major>.<minor>.<patch> version number should unpin and/or redeploy to use the latest patched images as soon as they are available. Subscribe to Dataproc release notes to get notified when patched images are available.
Google Cloud SQL The infrastructure that runs Google Cloud SQL and isolates database instances from each other is protected against known attacks.	No additional user or customer action is required.
Google Compute Engine The infrastructure that runs Google Compute Engine and isolates customer workloads from each other is protected against known attacks. Compute Engine customers running multi-tenant workloads on a single VM may be vulnerable. In this environment, it may be possible for one tenant to observe the memory of other tenants or the guest operating system itself.	The host infrastructure that runs Compute Engine isolates customer workloads from each other. Unless you are running untrusted code inside your VMs, no further action is required. Customers running untrusted workloads in their own multi-tenant services within Compute Engine virtual machines should follow the recommendations of their Guest OS Vendor.  As always, all Compute Engine customers are encouraged to follow security best practices when it comes to keeping runtime environments patched and protected against known security vulnerabilities. See the Compute Engine security bulletin for guidance on updating your Compute Engine VMs, the list of patched image versions, and links to additional information from operating system providers.
Google Kubernetes Engine The infrastructure that runs Kubernetes Engine and isolates customer Clusters and Nodes from each other is protected against known attacks. Kubernetes Engine customers running workloads with different trust levels on the same GKE Node, for example multi-tenant clusters, are vulnerable. In this environment, it may be possible for one container to observe the memory of other containers on the same Node or the Node environment itself.	Unless you are running untrusted code inside your containers, no further action is required. Customers running untrusted workloads in their own multi-tenant clusters, so that GKE Nodes are shared, should follow recommendations for their Node OS. For Container-Optimized OS (COS) nodes, you must disable hyper-threading and update to the latest patch version. See the Kubernetes Engine security bulletin for guidance on mitigating this vulnerability in your Kubernetes Engine environment.

 

Published on 2019-05-14.