From time to time, we might release security bulletins related to Compute Engine. All security bulletins for Compute Engine are described here.
Use this XML feed to subscribe to Compute Engine security bulletins.
GCP-2024-040
Published: 2024-07-01Updated: 2024-08-20
| Description | Severity | Notes |
|---|---|---|
| Updated: 2024-08-20 | Critical | CVE-2024-6387 |
2024-08-20: Include patches for TPUs. Apply updates from Linux distributions as they become available. Please refer to guidance from Linux distributions. If you are using TPUs, please update to one of the following patched versions:
A vulnerability (CVE-2024-6387) has been discovered in OpenSSH. Successful
exploitation of this vulnerability allows a remote, unauthenticated attacker
to execute arbitrary code as root on the target machine.
What should I do?
|
Critical | CVE-2024-6387 |
GCP-2024-021
Published: 2024-04-03| Description | Severity | Notes |
|---|---|---|
|
Compute Engine is not affected by CVE-2024-3094, which affects versions 5.6.0 and 5.6.1 of the xz-utils package in the liblzma library, and could lead to compromise of the OpenSSH utility. What should I do?Public images supported and offered by Compute Engine are not affected by this CVE. If you use Compute Engine public images for your VMs, no action is required. You could be at risk if you created a custom image that used versions 5.6.0 and 5.6.1 of xz-utils package, such as the following operating systems: To mitigate this risk, stop any VMs that use these operating systems or others that could have used affected operating systems. If you have VMs built from custom images of other operating systems, check with your OS vendor to see if your VMs are affected. What vulnerabilities are being addressed? |
Medium | CVE-2024-3094 |
GCP-2024-001
Published: 2024-01-09| Description | Severity | Notes |
|---|---|---|
|
Several vulnerabilities were discovered in the TianoCore EDK II UEFI firmware. This firmware is used in Google Compute Engine VMs. If exploited, the vulnerabilities could allow a bypass of secure boot, which would provide false measurements in the secure boot process, including when used in Shielded VMs. What should I do?No action is required. Google has patched this vulnerability across Compute Engine and all VMs are protected from this vulnerability. What vulnerabilities are addressed by this patch?The patch mitigated the following vulnerabilities:
|
Medium |
GCP-2023-44
Published: 2023-11-15| Description | Severity | Notes |
|---|---|---|
|
On November 14, AMD disclosed multiple vulnerabilities that impact various AMD server CPUs. Specifically, the vulnerabilities impact EPYC Server CPUs leveraging Zen core generation 2 "Rome," gen 3 "Milan," and gen 4 "Genoa." Google has applied fixes to affected assets, including Google Cloud, to ensure customers are protected. At this time, no evidence of exploitation has been found or reported to Google. What should I do?No customer action is required. Fixes have already been applied to the Google server fleet for Google Cloud, including Google Compute Engine. What vulnerabilities are addressed by this patch?The patch mitigated the following vulnerabilities:
For more information, see AMD's security advisory AMD-SN-3005: "AMD INVD Instruction Security Notice", also published as CacheWarp, and AMD-SN-3002: "AMD Server Vulnerabilities – November 2023". |
Medium |
GCP-2023-004
Published: 2023-04-26| Description | Severity | Notes |
|---|---|---|
|
Two vulnerabilities (CVE-2023-1017 and CVE-2023-1018) were discovered in Trusted Platform Module (TPM) 2.0. The vulnerabilities could have allowed a sophisticated attacker to exploit a 2-byte out of bounds read/write on certain Compute Engine VMs. What should I do?A patch was automatically applied to all vulnerable VMs. No customer action is required. What vulnerabilities are addressed by this patch?The patch mitigated the following vulnerabilities: CVE-2023-1017With CVE-2023-2017, a buffer overrun could be triggered in the vTPM parameter decryption routine. A local attacker running on a vulnerable VM could use this to trigger a denial-of-service or possibly execute arbitrary code in the vTPM context. CVE-2023-1018With CVE-2023-2018, an out-of-bounds read existed in the vTPM parameter decryption routine. A local attacker running on a vulnerable VM could use this to indirectly leak limited data from the vTPM context. |
Medium |
GCP-2021-026
Published: 2021-12-14| Description | Severity | Notes |
|---|---|---|
|
The Apache Log4j utility is a commonly used component for logging requests. On December 9, 2021, a vulnerability was reported that could allow a system running Apache Log4j version 2.14.1 or below to be compromised and allow an attacker to execute arbitrary code. On December 10, 2021, NIST published a critical Common Vulnerabilities and Exposure alert, CVE-2021-44228. More specifically, Java Naming Directory Interface (JNDI) features used in configuration, log messages, and parameters don't protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from remote servers when message lookup substitution is enabled. What should I do?
|
Critical |
GCP-2021-001
Published: 2021-01-28| Description | Severity | Notes |
|---|---|---|
|
A vulnerability was recently discovered in the Linux utility Compute Engine impactThe underlying infrastructure that runs Compute Engine is not impacted by this vulnerability. Compute Engine VMs running Linux should consider updating their guest operating system. For example, if you use a Container-Optimized OS, we recommend you update to one of the following images: cos-85-13310-1209-7, cos-81-12871-1245-6, cos-dev-89-16091-0-0, or later. |
None |
Date published: 2020-08-27
| Description | Severity | Notes |
|---|---|---|
|
Eclypsium has disclosed the following CVE: CVE-2020-10713. VulnerabilitiesIn response to the initial vulnerability report, additional scrutiny was applied to the GRUB2 code and the following additional vulnerabilities were discovered by Canonical:
These vulnerabilities, collectively referred to as BootHole, allow unsigned binaries to be loaded by attackers with administrative privileges, thus disabling secure boot enforcement. Compute Engine impactThe host infrastructure that runs Compute Engine is protected against known attacks. Compute Engine customers who use secure boot are encouraged to update the guest operating systems on their instances to prevent the possibility of exploitation within their guest environments. For details, refer to your Guest OS Vendor's recommended mitigation. Patched images and vendor resourcesWe will provide links to patch information from each operating system vendor here as they become available. Earlier versions of these public images don't contain these patches and don't mitigate potential attacks:
|
High |
Date published: 2020-06-19
| Description | Severity | Notes |
|---|---|---|
|
VMs that have OS Login enabled might be susceptible to privilege escalation vulnerabilities. These vulnerabilities gives users that are granted OS Login permissions (but not given administrator access) the ability to escalate to root access in the VM. VulnerabilitiesThe following three vulnerabilities, which are due to overly permissive default group memberships, were identified for Compute Engine images:
Patched images and fixes
All Compute Engine public images created after
If you need to fix this issue without updating to a later version of your
image, you can edit the |
High |
Date published: 2020-01-21
| Description | Severity | Notes |
|---|---|---|
|
Microsoft disclosed the following vulnerability:
Compute Engine impactThe underlying infrastructure that runs Compute Engine is not impacted by this vulnerability. Unless you are running Windows Server in your Compute Engine virtual machine, no further action is required. Customers using Compute Engine VMs running Windows Server should ensure their instances have the latest Windows patch. Patched images and vendor resourcesEarlier versions of the public Windows images don't contain the following patches and don't mitigate potential attacks:
|
Medium |
Date published: 2019-11-12
| Description | Severity | Notes |
|---|---|---|
|
Intel has disclosed the following CVEs:
Compute Engine impactCVE-2019-11135The host infrastructure that runs Compute Engine isolates customer workloads. Unless you are running untrusted code inside N2, C2, or M2 VMs, no further action is required. N2, C2, or M2 customers running untrusted code in their own multi-tenant services within Compute Engine virtual machines should stop and start their VMs in order to ensure they have the latest security mitigations. A reboot, without a stop/start, is not sufficient. This guidance assumes you have already applied previously released updates covering the MDS vulnerability. If not, please follow the instructions to apply the appropriate updates. For customers running N1 machine types, no action is required, as this vulnerability does not represent new exposure beyond the previously disclosed MDS vulnerabilities. CVE-2018-12207The host infrastructure that runs Compute Engine is protected from this vulnerability. No further action is required. |
Medium |
Date published: 2019-06-18
last updated: 2019-06-25 T 6:30 PST
| Description | Severity | Notes |
|---|---|---|
|
Netflix has recently disclosed three TCP vulnerabilities in Linux kernels: These CVEs are collectively referred to as NFLX-2019-001. Compute Engine impactThe infrastructure that hosts Compute Engine is protected from this vulnerability. Compute Engine VMs running unpatched Linux operating systems that send/receive untrusted network traffic are vulnerable to this DoS attack. Consider updating these VM instances as soon as patches are available for their operating systems. Load balancers that close TCP connections have been patched against this vulnerability. Compute Engine instances that receive only untrusted traffic through these load balancers are not vulnerable. This includes HTTP Load Balancers, SSL Proxy Load Balancers, and TCP Proxy Load Balancers. Network load balancers and internal load balancers don't close TCP connections. Unpatched Compute Engine instances that receive untrusted traffic through these load balancers are vulnerable. Patched images and vendor resourcesWe will provide links to patch information from each operating system vendor here as they become available, including the status for each CVE. Earlier versions of these public images don't contain these patches and don't mitigate potential attacks:
|
Medium |
Date published: 2019-05-14
last updated: 2019-05-20 T 17:00 PST
| Description | Severity | Notes |
|---|---|---|
|
Intel has disclosed the following CVEs: These CVEs are collectively referred to as Microarchitectural Data Sampling (MDS). These vulnerabilities potentially allow data to be exposed using the interaction of speculative execution with microarchitectural state. Compute Engine impactThe 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. For customers running untrusted code in their own multi-tenant services within Compute Engine virtual machines, refer to your Guest OS Vendor's recommended mitigation, which might include using Intel's microcode mitigation features. We have deployed guest pass-through access to the new flush functionality. The following is a summary of mitigation steps available for common guest images. Patched images and vendor resourcesWe will provide links to patch information from each operating system vendor here as they become available, including status for each CVE. Use these images to recreate VM instances. Earlier versions of these public images don't contain these patches and don't mitigate potential attacks:
Container-Optimized OSIf you are using Container Optimized OS (COS) as your Guest OS and you are running untrusted, multi-tenant workloads in your virtual machine, we recommend that you:
|
Medium |
Date published: 2018-08-14
last updated: 2018-08-20 T 17:00 PST
| Description | Severity | Notes |
|---|---|---|
DescriptionIntel has disclosed the following CVEs:
These CVEs are collectively referred to as "L1 Terminal Fault (L1TF)". These L1TF vulnerabilities exploit speculative execution by attacking the configuration of processor-level data structures. "L1" refers to the Level-1 Data cache (L1D), a small on-core resource used to accelerate memory access. Read the Google Cloud blog post for more details on these vulnerabilities and Compute Engine's mitigations. Compute Engine impactThe host infrastructure that runs Compute Engine and isolates customer workloads from each other is protected against known attacks. Compute Engine customers are encouraged to update their images to prevent the possibility of indirect exploitation within their guest environments. This is particularly important for customers running their own multi-tenant services on Compute Engine virtual machines. Compute Engine customers can update the guest operating systems on their instances using one of the following options:
Patched images and vendor resourcesWe will provide links to patch information from each operating system vendor here as they become available, including status for both CVEs. Use these images to recreate VM instances. Earlier versions of these public images don't contain these patches and don't mitigate potential attacks:
|
High |
Date published: 2018-08-06
last updated: 2018-09-05 T 17:00 PST
| Description | Severity | Notes |
|---|---|---|
2018-09-05 UpdateCVE-2018-5391 was disclosed on 2018-08-14 by US-CERT. As with CVE-2018-5390, this is a kernel-level networking vulnerability that increases the effectiveness of denial of service (DoS) attacks against vulnerable systems. The main difference is that CVE-2018-5391 is exploitable over IP connections. We updated this bulletin to cover both vulnerabilities. DescriptionCVE-2018-5390 ("SegmentSmack") describes a kernel-level networking vulnerability that increases the effectiveness of denial of service (DoS) attacks against vulnerable systems over TCP connections. CVE-2018-5391 ("FragmentSmack") describes a kernel-level networking vulnerability that increases the effectiveness of denial of service (DoS) attacks against vulnerable systems over IP connections. Compute Engine impactThe host infrastructure that runs Compute Engine VMs is not at risk. The network infrastructure that handles traffic to and from Compute Engine VMs is protected against this vulnerability. Compute Engine VMs that only send/receive untrusted network traffic using HTTP(S), SSL, or TCP Load Balancers are protected against this vulnerability. Compute Engine VMs running unpatched operating systems that send/receive untrusted network traffic directly, or using Network Load Balancers, are vulnerable to this DoS attack. Consider updating your VM instances as soon as patches are available for their operating systems. Compute Engine customers can update the guest operating systems on their instances using one of the following options:
Patched images and vendor resourcesWe will provide links to patch information from each operating system vendor here as they become available.
|
High |
Date published: 2018-01-03
last updated: 2018-05-21 T 15:00 PST
| Description | Severity | Notes |
|---|---|---|
2018-05-21 UpdateCVE-2018-3640 and CVE-2018-3639, Variants 3a and 4 respectively, were disclosed by Intel. As with the first three variants of Spectre and Meltdown, the infrastructure that runs Compute Engine VM instances is protected and customer VM instances are isolated and protected from one another. Additionally, Compute Engine plans to deploy Intel's microcode patches to our infrastructure, which will allow customers who run untrusted or multi-tenant workloads within a single VM instance to enable additional intra-VM mitigations when those mitigations are provided by operating system vendors and providers. Compute Engine will deploy the microcode patches once Intel has certified them and after Compute Engine has tested and qualified the patches for our production environment. We will provide more detailed timelines and updates on this page as they become available. DescriptionThese CVEs are variants of a new class of attack that exploit the speculative execution technology available in many processors. This class of attack can allow for unauthorized read-only access to memory data under various circumstances. Compute Engine used VM Live Migration technology to perform host system and hypervisor updates with no user impact, no forced maintenance windows, and no mass reboots required. However, all guest operating systems and versions must be patched to protect against this new class of attack regardless of where those systems run. Read the Project Zero blog post for complete technical details on this attack method. Read the Google Security blog post for complete details on Google's mitigations including all product-specific information. Compute Engine impactThe infrastructure that runs Compute Engine and isolates customer VM instances from each other is protected against known attacks. Our mitigations prevent unauthorized access to our host systems from applications running inside VM instances. These mitigations also prevent unauthorized access between VM instances running on the same host system. To prevent unauthorized access within your virtual machine instances, you must update the guest operating systems on those instances using one of the following options:
Patched images and vendor resourcesNote: Patched images might not include fixes for all of the CVEs listed in this security bulletin notice. Additionally, different images might include different methods for preventing these types of attacks. Check with your operating system vendor to confirm which CVEs they address in their patches and what prevention methods they use.
Use these images to recreate your VM instances. Earlier versions of these public images don't contain these patches and don't mitigate potential attacks. Patches from hardware vendorsNVIDIA provides patched drivers to mitigate potential attacks against systems that have NVIDIA® driver software installed. To learn which driver versions are patched, read the NVIDIA GPU Display Driver Security Updates security bulletin from NVIDIA. Revision history:
|
High |
Date published: 2017-10-02
| Description | Severity | Notes |
|---|---|---|
|
Dnsmasq provides functionality for serving DNS, DHCP, router advertisements, and network boot. This software is commonly installed in systems as varied as desktop Linux distributions (like Ubuntu), home routers, and IoT devices. Dnsmasq is widely used both on the open Internet and internally in private networks. Google discovered seven distinct issues over the course of our regular internal security assessments. After we determined the severity of these issues, we worked to investigate their impact and exploitability and then produced internal proofs of concept for each of them. We also worked with the maintainer of Dnsmasq, Simon Kelly, to produce appropriate patches and mitigate the issue. During our review, the team found three potential remote code executions, one information leak, and three denial of service vulnerabilities affecting the latest version at the project git server as of September 5th 2017. These patches are upstreamed and are committed to the project's Git repository. Compute Engine impactBy default, Dnsmasq is only installed in images that use NetworkManager and is inactive by default. The following Compute Engine public images have Dnsmasq installed:
However, other images might have Dnsmasq installed as a dependency for other packages. We recommend that you update your Debian, Ubuntu, CentOS, RHEL, SLES, and OpenSuse instances to use the latest operating system image. CoreOS and Container-Optimized OS are not affected. Windows images are also unaffected. For instances running Debian and Ubuntu, you can perform an update by running the following commands in your instance: sudo apt-get -y update sudo apt-get -y dist-upgrade For Red Hat Enterprise Linux and CentOS instances, run: sudo yum -y upgrade For SLES and OpenSUSE images, run: sudo zypper up As an alternative to running the manual update commands, you can recreate VM instances using the image families of the respective operating system. |
High |
Date published: 2016-10-26
| Description | Severity | Notes |
|---|---|---|
|
CVE-2016-5195 is a race condition in the way Linux kernel's memory subsystem handled breakage of the read-only private mappings COW situation on write access. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system. For more information see the Dirty COW FAQ. Compute Engine impactAll Linux distributions and versions on Compute Engine are affected. Most instances will automatically download and install a newer kernel. However, a reboot is required to patch your running system. New or re-created instances based on the following Compute Engine images have patched kernels installed already.
|
High | CVE-2016-5195 |
Date published: 2016-02-16
Last updated: 2016-02-22
| Description | Severity | Notes |
|---|---|---|
|
CVE-2015-7547 is a vulnerability where the glibc DNS client side
resolver makes software vulnerable to a stack-based buffer
overflow when using the For more details, see the Google Security blog postor the Common Vulnerabilities and Exposures (CVE) database. Compute Engine impactUpdate (2016-02-22): You can now recreate your instances using the following CoreOS, SLES, and OpenSUSE images:
Update (2016-02-17): You can now perform an update on Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, and Ubuntu 15.10 instances by running the following commands:
As an alternative to running the manual update commands, you can now recreate their instances with the following new images:
We are not aware of any methods that can exploit this vulnerability through Compute Engine's DNS resolvers with the default glibc configuration. We recommend you patch your virtual machine instances as soon as possible, since, as with any new vulnerability, new exploit methods might be discovered over time. If you have enabled edns0 (disabled by default), you should disable it until your instances are patched. Original bulletin: Your Linux distribution might be vulnerable. Compute Engine customers will need to update the OS images of their instances to eliminate this vulnerability if they are running a Linux OS. For instances running Debian, you can perform an update by running the following commands in your instance:
We also recommend installing UnattendedUpgrades for your Debian instances. For Red Hat Enterprise Linux instances:
We will continue to update this bulletin as other operating system maintainers publish patches for this vulnerability and as Compute Engine releases updated OS images. |
High | CVE-2015-7547 |
Date published: 2015-03-19
| Description | Severity | Notes |
|---|---|---|
|
CVE-2015-1427 is a vulnerability where the Groovy scripting engine in Elasticsearch before version 1.3.8 and any 1.4.x versions before 1.4.3, allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands. For more details, see the National Vulnerability Database (NVD) or the Common Vulnerabilities and Exposures (CVE) database. Compute Engine impactIf you are running Elasticsearch on your Compute Engine instances, you should upgrade your Elasticsearch version to 1.4.3 or higher. If you have already upgraded your Elasticsearch software, you are protected from this vulnerability. If you have not upgraded Elasticsearch 1.4.3 or higher, you can perform a rolling upgrade. If you deployed Elasticsearch using Click-to-deploy in the Google Cloud console, you can delete the deployment to remove instances running Elasticsearch. The Google Cloud team is working on a fix in order to deploy an updated version of Elasticsearch. However, the fix is not yet available for the Click-to-deploy feature in the Google Cloud console . |
High | CVE-2015-1427 |
Date published: 2015-01-29
| Description | Severity | Notes |
|---|---|---|
|
CVE-2015-0235 (Ghost) is a vulnerability in the glibc library. App Engine, Cloud Storage, BigQuery, and Cloud SQL customers don't need to take any actions. Google servers have been updated and are protected from this vulnerability. Customers of Compute Engine may need to update their OS images. Compute Engine impactYour Linux distribution may be vulnerable. Compute Engine customers will need to update the OS images of their instances to eliminate this vulnerability if they are running Debian 7, Debian 7 backports, Ubuntu 12.04 LTS, Red Hat Enterprise Linux, CentOS, or SUSE Linux Enterprise Server 11 SP3. This vulnerability does not affect Ubuntu 14.04 LTS, Ubuntu 14.10, or SUSE Linux Enterprise Server 12. We recommend that you upgrade your Linux distributions. For instances running Debian 7, Debian 7 backports, or Ubuntu 12.04 LTS, you can perform an update by running the following commands in your instance:
For Red Hat Enterprise Linux or CentOS instances:
For SUSE Linux Enterprise Server 11 SP3 instances:
As an alternative to running the manual update commands above, users can now recreate their instances with the following new images:
Google Managed VM impactManaged VM users using |
High | CVE-2015-0235 |
Date published: 2014-10-15
Last updated: 2014-10-17
| Description | Severity | Notes |
|---|---|---|
|
CVE-2014-3566 (aka POODLE) is a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker. For details, see our blog post on the vulnerability. App Engine, Cloud Storage, BigQuery, and Cloud SQL customers don't need to take any actions. Google servers have been updated and are protected from this vulnerability. Customers of Compute Engine need to update their OS images. Compute Engine impactUpdated (2014-10-17): You may be vulnerable if you are using SSLv3. Compute Engine customers will need to update the OS images of their instances to eliminate this vulnerability. We recommend that you upgrade your Linux distributions. For instances running Debian, you can perform an update by running the following commands in your instance: user@my-instance:~$ sudo apt-get update user@my-instance:~$ sudo apt-get -y upgrade user@my-instance:~$ sudo reboot For CentOS instances: user@my-instance:~$ sudo yum -y upgrade user@my-instance:~$ sudo reboot As an alternative to running the manual update commands above, users can now recreate their instances with the following new images to recreate your instances:
We will update the bulletin for RHEL and SLES images after we have the images. In the meantime, RHEL users can consult Red Hat directly for more information. Original bulletin: Compute Engine customers will need to update the OS images of their instances to eliminate this vulnerability. We will update this security bulletin with instructions once new OS images are available. |
Medium | CVE-2014-3566 |
Date published: 2014-09-24
last updated: 2014-09-29
| Description | Severity | Notes |
|---|---|---|
|
There is a bug in bash (CVE-2014-6271) that allows remote code execution based on parsing of any attacker-controlled environment variables. The most likely vector of exploitation is using malicious HTTP requests made to CGI scripts exposed on a web server. For more information, see the bug description. The bash bugs have been mitigated for Google Cloud products except for Compute Engine guest OS images dated before 20140926. Please see below for steps to mitigate the bugs for your Compute Engine images. Compute Engine impact
This bug may affect virtually all websites that use CGI scripts. In
addition, it will likely affect web sites that rely on PHP, Perl,
Python, SSI, Java, C++, and similar servlets that will ever invoke
shell commands using calls such as Update (2014-09-29): As an alternative to running the manual update commands below, users can now recreate their instances with images that mitigate additional vulnerabilities related to the bash security bug, including CVE-2014-7169, CVE-2014-6277, CVE-2014-6278, CVE-2014-7186, and CVE-2014-7187. Use the following new images to recreate your instances:
Update (2014-09-25): Users can now choose to recreate their instances instead of performing a manual update. To recreate your instances, use the following new images which contains fixes to this security bug:
For RHEL and SUSE images, you can also manually perform updates by running the following commands on your instances: # RHEL instances user@my-instance:~$ sudo yum -y upgrade # SUSE instances user@my-instance:~$ sudo zypper --non-interactive up Original bulletin: We recommend that you upgrade your Linux distributions. For instances running Debian, you can perform an update by running the following commands in your instance: user@my-instance:~$ sudo apt-get update user@my-instance:~$ sudo apt-get -y upgrade For CentOS instances: user@my-instance:~$ sudo yum -y upgrade For detailed information, review the announcement for the respective Linux distribution:
|
High | CVE-2014-7169, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278 CVE-2014-7186, CVE-2014-7187 |
Date published: 2014-07-25
| Description | Severity | Notes |
|---|---|---|
|
Elasticsearch Logstash is vulnerable to OS command injection that can allow unauthorized modification and disclosure of data. An attacker can send crafted events to any of Logstash's data sources, allowing the attacker to execute commands with the permissions of the Logstash process. Compute Engine impactThis vulnerability affects all Compute Engine instances running versions of Elasticsearch Logstash before 1.4.2 with zabbix or nagios_nsca outputs enabled. To prevent attack, you can either:
Read more on the Logstash blog. Elasticsearch also recommends using a firewall to prevent remote access by untrusted IPs. |
High | CVE-2014-4326 |
Date published: 2014-06-18
| Description | Severity | Notes |
|---|---|---|
|
We would like to take a moment to respond to any possible concerns that customers have about the security of Docker containers when running on Google Cloud. This includes customers using our App Engine extensions that support Docker Containers, container optimized virtual machines, or the Open Source Kubernetes scheduler. Docker has done a great job of responding to the issue and you can see their blog response here. Note that, as they say in their response, the issue revealed applies only to Docker 0.11, an older, pre-production, version. While the world is thinking about container security, we would like to point out that in Google Cloud, Linux application container based solutions (specifically Docker containers) run in full virtual machines (Compute Engine). While we support the efforts of the Docker community to harden the Linux application container stack, we recognize that the technology is new, and the surface area large. It is our belief that, for now, full hypervisors (virtual machines) provide a more compact and defensible surface area. Virtual machines were designed from the beginning to isolate malicious workloads and to minimize the likelihood and impact of a code bug. Our customers can rest assured that a full hypervisor boundary exists between them and any third party, potentially malicious code. Should we reach a point where we consider the Linux application container stack robust enough to support multi-tenant workloads, we will let the community know. For now, the Linux application container does not replace the virtual machine. It is a way to get a lot more out of it. |
Low | Docker blog post |
Date published: 2014-06-05
Last updated: 2014-06-09
| Description | Severity | Notes |
|---|---|---|
|
OpenSSL has an issue where the This issue is identified as CVE-2014-0224. The OpenSSL team has fixed the issue and alerted the OpenSSL community to update OpenSSL. Compute Engine impactThis vulnerability affects all Compute Engine instances which use OpenSSL, including Debian, CentOS, Red Hat Enterprise Linux, and SUSE Linux Enterprise Server. You can update your instances by recreating them with new images, or by manually updating packages on your instances. Update (2014-06-09): To update your instances running SUSE Linux Enterprise Server with new images, recreate your instances using the following image versions or higher:
Original post: To update Debian and CentOS instances using new images, recreate your instances using any of the following image versions or higher:
To manually update OpenSSL on your instances, run the following commands to update the appropriate packages. For instances running CentOS and RHEL, you can update OpenSSL by running these commands in your instance: user@my-instance:~$ sudo yum -y update user@my-instance:~$ sudo reboot For instances running Debian, you can update OpenSSL by running the following commands in your instance: user@my-instance:~$ sudo apt-get update user@my-instance:~$ sudo apt-get -y upgrade user@my-instance:~$ sudo reboot For instances running SUSE Linux Enterprise Server, you can ensure OpenSSL is up to date by running these commands in the instance: user@my-instance:~$ sudo zypper --non-interactive up user@my-instance:~$ sudo reboot |
Medium | CVE-2014-0224 |
Date published: 2014-04-08
| Description | Severity | Notes |
|---|---|---|
|
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before
1.0.1g don't properly handle Heartbeat Extension packets, which
allows remote attackers to obtain sensitive information from process
memory using crafted packets that trigger a buffer over-read, as
demonstrated by reading private keys, related to
Compute Engine impactThis vulnerability affects all Compute Engine Debian, RHEL, and CentOS instances that don't have the most updated version of OpenSSL. You can update your instances by recreating them with new images, or by manually updating packages on your instances. To update your instances using new images, recreate your instances using any of the following image versions or higher:
To manually update OpenSSL on your instances, run the following commands to update the appropriate packages. For instances running CentOS and RHEL, you can ensure OpenSSL is up to date by running these commands in the instance: user@my-instance:~$ sudo yum update user@my-instance:~$ sudo reboot For instances running Debian, you can update OpenSSL by running the following commands in your instance: user@my-instance:~$ sudo apt-get update user@my-instance:~$ sudo apt-get upgrade user@my-instance:~$ sudo reboot Instances running SUSE Linux are not affected. Update on April 14, 2014: In light of new research on extracting keys using the Heartbleed bug, Compute Engine is recommending that Compute Engine customers create new keys for any affected SSL services. |
Medium | CVE-2014-0160 |
Date published: 2013-06-07
| Description | Severity | Notes |
|---|---|---|
|
Note: This vulnerability is only applicable for kernels, which have been deprecated and removed since API version v1.
Format string vulnerability in the Compute Engine impact
This vulnerability affects all Compute Engine kernels earlier than
To find out what kernel version your instance is using:
|
Medium | CVE-2013-2852 |
Date published: 2013-06-07
| Description | Severity | Notes |
|---|---|---|
|
Note: This vulnerability is only applicable for kernels, which have been deprecated and removed since API version v1.
Format string vulnerability in the register_disk function in
Compute Engine Impact
This vulnerability affects all Compute Engine kernels earlier than
To find out what kernel version your instance is using:
|
Medium | CVE-2013-2851 |
Date published: 2013-05-14
| Description | Severity | Notes |
|---|---|---|
|
Note: This vulnerability is only applicable for kernels, which have been deprecated and removed since API version v1.
The perf_swevent_init function in Compute Engine impact
This vulnerability affects all Compute Engine kernels earlier than
To find out what kernel version your instance is using:
|
High | CVE-2013-2094 |
Date published: 2013-02-18
| Description | Severity | Notes |
|---|---|---|
|
Note: This vulnerability is only applicable for kernels, which have been deprecated and removed since API version v1.
Race condition in the ptrace functionality in the Linux kernel before
3.7.5 allows local users to gain privileges using a Compute Engine impact
This vulnerability affects Compute Engine kernels
To find out what kernel version your instance is using:
|
Medium | CVE-2013-0871 |