Sicherheitsbulletins

Von Zeit zu Zeit veröffentlichen wir Sicherheitsbulletins im Zusammenhang mit Compute Engine. Sämtliche Sicherheitsbulletins zu Compute Engine sind hier beschrieben.

Verwenden Sie diesen XML-Feed, um Sicherheitsbulletins für Compute Engine zu abonnieren. Abonnieren

GCP-2025-058

Veröffentlicht: 20.10.2025

Beschreibung

Beschreibung Schweregrad Hinweise

In der RDSEED-Anweisung in AMD Zen 5-Prozessoren (Turin) wurde ein Fehler entdeckt. Mit dieser Anweisung werden kryptografische Zufallszahlen generiert. Unter bestimmten Systemlastbedingungen können die 16- und 32-Bit-Versionen von RDSEED ohne Fehlermeldung fehlschlagen, was Anwendungen, die auf die Generierung von Zufallszahlen angewiesen sind, beeinträchtigen kann. Kunden, die die 64-Bit-Version von RDSEED verwenden, sind nicht betroffen.

Wie gehe ich am besten vor?

AMD untersucht die Sicherheitslücke.

Der 64-Bit-Linux-Kernel verwendet die sichere 64-Bit-Version des RDSEED-Befehls, der die Zufallszahlen aus /dev/[u]random liefert. Diese Zufallszahlen sind von dieser Sicherheitslücke nicht betroffen.

Wenn Sie Anwendungscode haben, der selbst Zufallszahlen mit dem RDSEED-Befehl generiert, beachten Sie, dass die 16-Bit- und 32-Bit-Versionen des Befehls unsicher sind. Die 64-Bit-Version der Anweisung ist sicher.

Welche Sicherheitslücken werden behoben?

Diese Sicherheitslücke ermöglicht es einem Angreifer, RDSEED zum stillen Fehlschlagen zu bringen, wodurch möglicherweise die Zufallszahlengenerierung in Anwendungen beeinträchtigt wird.

Hoch

GCP-2025-044

Veröffentlicht: 12.08.2025

Beschreibung

Beschreibung Schweregrad Hinweise

Intel hat Google über zwei neue Sicherheitslücken informiert.

CVE-2025-21090: Diese Sicherheitslücke betrifft die folgenden Intel-Prozessoren:

  • Sapphire Rapids: VM-Familien C3, Z3, H3, A3, v5p
  • Emerald Rapids: N4-, C4-, M4-, A3 Ultra- und A4-VM-Familien
  • Granite Rapids: N4-, C4-VM-Familie

CVE-2025-22840: Diese Sicherheitslücke betrifft den folgenden Intel-Prozessor:

  • Granite Rapids: N4-, C4-VM-Familie

Wie gehe ich am besten vor?

Auf Kundenseite sind keine Maßnahmen erforderlich. Google aktualisiert Ihre Systeme proaktiv während Ihrer standardmäßigen und geplanten Wartungsfenster. Derzeit gibt es keine Hinweise auf eine Ausnutzung oder entsprechende Meldungen an Google.

Welche Sicherheitslücken werden behoben?

Die Sicherheitslücke CVE-2025-21090 ermöglicht es einem nicht privilegierten Akteur, die AMX-CPU-Anweisung in Verbindung mit der AVX-CPU-Anweisung zu verwenden, um den Hostcomputer funktionsunfähig zu machen.

Die Sicherheitslücke CVE-2025-22840 ermöglicht es einem nicht privilegierten Akteur, mit dem CPU-Befehl „prefetchit“ Speicherinhalte zu laden, auf die er sonst keinen Zugriff hätte. Dies kann möglicherweise zur Ausführung von Remote-Code führen.

Mittel

GCP-2025-042

Veröffentlicht: 11.08.2025

Beschreibung

Beschreibung Schweregrad Hinweise

Forscher haben eine Sicherheitslücke in bestimmten Intel-CPUs entdeckt, darunter solche, die auf den Mikroarchitekturen Skylake, Broadwell und Haswell basieren. Diese Sicherheitslücke ermöglicht es einem Angreifer, möglicherweise vertrauliche Daten direkt aus dem L1-Cache der CPU zu lesen, auf die er nicht zugreifen darf.

Diese Sicherheitslücke wurde 2018 erstmals in CVE-2018-3646 offengelegt. Nachdem diese Sicherheitslücke entdeckt wurde, hat Google sofort Maßnahmen ergriffen, um die bekannten Risiken zu minimieren. Die Kommunikation bezüglich der Sicherheitslücke und der ersten Korrekturen wurde zu diesem Zeitpunkt veröffentlicht. Seitdem untersuchen wir das Restrisiko und arbeiten mit der Upstream-Linux-Community zusammen, um es zu minimieren.

Vor Kurzem haben wir mit Sicherheitsforschern aus der Wissenschaft zusammengearbeitet, um den aktuellen Stand der CPU-Sicherheitsmaßnahmen und potenzielle Angriffstechniken zu bewerten, die 2018 noch nicht berücksichtigt wurden.

Google hat Korrekturen an den betroffenen Assets, einschließlich Google Cloud, vorgenommen, um das Problem zu beheben.

Wie gehe ich am besten vor?

Auf Kundenseite sind keine Maßnahmen erforderlich. Es wurden bereits Maßnahmen auf der Google-Serverflotte ergriffen.

Welche Sicherheitslücken werden behoben?

Weitere Informationen finden Sie in der Intel-Sicherheitsempfehlung INTEL-SA-00161 und unter CVE-2018-3646.

Hoch CVE-2018-3646

GCP-2025-031

Veröffentlicht: 10.06.2025

Beschreibung

Beschreibung Schweregrad Hinweise

Die Trusted Computing Group (TCG) hat eine Softwarelücke im Trusted Platform Module (TPM) gemeldet, die sich auf Shielded VMs mit virtuellem TPM (vTPM) auswirkt. Diese Sicherheitslücke ermöglicht es einem authentifizierten lokalen Angreifer, vertrauliche vTPM-Daten zu lesen oder die vTPM-Verfügbarkeit zu beeinträchtigen.

Der Zugriff auf vTPM ist in der Regel privilegiert. Einige Konfigurationen ermöglichen jedoch möglicherweise einen umfassenderen vTPM-Zugriff.

Wie gehe ich am besten vor?

Auf Kundenseite sind keine Maßnahmen erforderlich. Google aktualisiert Ihre Systeme proaktiv während Ihrer standardmäßigen und geplanten Wartungsfenster. Sie können den vTPM-Zugriff jedoch auf administrative (Root-)Nutzer beschränken. Dadurch wird das Risiko für Ihre geschützten VMs verringert.

Welche Sicherheitslücken werden behoben?

Durch die Sicherheitslücke CVE-2025-2884 kann ein lokaler Angreifer mit Zugriff auf die vTPM-Schnittstelle schädliche Befehle senden. Diese Befehle nutzen eine Diskrepanz, die den vTPM-Speicher außerhalb des zulässigen Bereichs (Out-of-Bounds, OOB) ausliest. Durch diese Aktion können sensible Daten offengelegt werden.

Hoch CVE-2025-2884

GCP-2025-025

Veröffentlicht: 13.05.2025

Beschreibung

Beschreibung Schweregrad Hinweise

Intel hat Google über eine neue Seitenkanal-Sicherheitslücke informiert, die die folgenden Intel-Prozessoren betrifft: CascadeLake, Ice Lake XeonSP, Ice Lake XeonD, Sapphire Rapids und Emerald Rapids.

Google hat Korrekturen an den betroffenen Assets, einschließlich Google Cloud, vorgenommen, um Kunden zu schützen. Derzeit gibt es keine Beweise für eine Ausnutzung oder Berichte darüber an Google.

Was soll ich tun?

Auf Kundenseite sind keine Maßnahmen erforderlich. Auf die Google-Serverflotte wurden bereits Korrekturen angewendet, um Kunden zu schützen.

Welche Sicherheitslücken werden behoben?

CVE-2024-45332. Weitere Informationen finden Sie in der Intel-Sicherheitsempfehlung INTEL-SA-01247.

Wir sind für Sie da

Wenn Sie Fragen haben oder Unterstützung benötigen, wenden Sie sich bitte an Cloud Customer Care. Geben Sie dabei die Referenznummer 417536835 an.

Hoch CVE-2024-45332

GCP-2025-024

Veröffentlicht: 12.05.2025

Aktualisiert: 13.05.2025

Beschreibung

Beschreibung Schweregrad Hinweise

Aktualisierung vom 13.05.2025: Wenn Sie Fragen haben oder Unterstützung benötigen, wenden Sie sich an Cloud Customer Care und geben Sie die Referenznummer 417458390 an.


Intel hat Google über eine neue Sicherheitslücke bei der spekulativen Ausführung informiert, die Intel Cascade Lake- und Intel Ice Lake-Prozessoren betrifft.

Google hat Korrekturen an den betroffenen Assets, einschließlich Google Cloud, vorgenommen, um Kunden zu schützen. Derzeit gibt es keine Hinweise auf eine Ausnutzung oder Berichte darüber an Google.

Was soll ich tun?

Auf Kundenseite sind keine Maßnahmen erforderlich. Es wurden bereits Maßnahmen auf der Google-Serverflotte ergriffen.

Weitere Maßnahmen von Intel-Erstausrüstern (Original Equipment Manufacturers, OEMs) und anderen Betriebssystempartnern werden bereitgestellt, sobald sie verfügbar sind, um die Auswirkungen der Sicherheitslücke „Same-Mode Indirect Target Selection“ (ITS) zu minimieren.

Nachdem die Betriebssystem-Maßnahmen angewendet wurden, kann es bei Kunden mit VMs der 3. Generation oder höher, die lange ausgeführt werden, zu unbeabsichtigten Leistungseinbußen kommen.

Welche Sicherheitslücken werden behoben?

CVE-2024-28956. Weitere Informationen finden Sie in der Intel-Sicherheitsempfehlung INTEL-SA-01153.

Hoch CVE-2024-28956

GCP-2024-040

Veröffentlicht: 01.07.2024
Aktualisiert: 20.08.2024
Beschreibung Schweregrad Hinweise
Aktualisiert: 20.08.2024 Kritisch CVE-2024-6387

20.08.2024: Patches für TPUs einfügen Wenden Sie Updates von Linux-Distributionen an, sobald sie verfügbar sind. Weitere Informationen finden Sie in der Dokumentation der jeweiligen Linux-Distribution. Wenn Sie TPUs verwenden, aktualisieren Sie bitte auf eine der folgenden Patchversionen:

  • tpu-ubuntu2204-base
  • v2-alpha-tpuv5
  • v2-alpha-tpuv5-lite

In OpenSSH wurde eine Sicherheitslücke (CVE-2024-6387) entdeckt. Eine erfolgreiche Ausnutzung dieser Sicherheitslücke ermöglicht es einem nicht authentifizierten Remote-Angreifer, beliebigen Code als Root auf dem Zielcomputer auszuführen.

Es wird empfohlen, alle Compute Engine-VMs, die eine glibc-basierte Linux-Distribution verwenden und bei denen OpenSSH verfügbar ist, auf die anfälligen Versionen zu analysieren.

Wie gehe ich am besten vor?

  1. Wenden Sie Updates von Linux-Distributionen an, sobald sie verfügbar sind. Weitere Informationen finden Sie in der Dokumentation der jeweiligen Linux-Distribution. Wenn Sie Container-Optimized OS von Google verwenden, aktualisieren Sie auf eine der folgenden gepatchten Versionen:
    • cos-113-18244-85-49
    • cos-109-17800-218-69
    • cos-105-17412-370-67
    • cos-101-17162-463-55
    Wenn Sie Container-Optimized OS über einen von Google verwalteten Dienst (z.B. GKE) verwenden, lesen Sie bitte das Sicherheitsbulletin des jeweiligen Dienstes, um Informationen zur Verfügbarkeit von Patches zu erhalten.
  2. Wenn ein Update nicht möglich ist, sollten Sie OpenSSH deaktivieren, bis es gepatcht werden kann. Das Standardnetzwerk enthält bereits eine default-allow-ssh-Firewallregel, die den SSH-Zugriff aus dem öffentlichen Internet zulässt. So können Kunden diesen Zugriff entfernen:
    1. Optional können Sie Regeln erstellen, um den erforderlichen SSH-Zugriff von vertrauenswürdigen Netzwerken auf GKE-Knoten oder andere Compute Engine-VMs im Projekt zuzulassen.
    2. Deaktivieren Sie die Standard-Firewallregel mit dem folgenden Befehl:
      gcloud compute firewall-rules update default-allow-ssh --disabled --project=$PROJECT
            
    Wenn Sie andere Firewallregeln erstellt haben, die möglicherweise SSH über TCP auf Port 22 zulassen, deaktivieren Sie sie oder beschränken Sie die Quell-IPs auf vertrauenswürdige Netzwerke.

    Prüfen Sie, ob Sie keine SSH-Verbindung mehr zu Ihren VMs über das Internet herstellen können. Diese Firewallkonfiguration mindert die Sicherheitslücke.
  3. Wenn OpenSSH aktiviert bleiben muss, können Sie auch ein Konfigurationsupdate ausführen, das die Race-Case-Bedingung für den Exploit beseitigt. Dies ist eine Laufzeit-Maßnahme. Damit die Änderungen in der SSHD-Konfiguration übernommen werden, wird der SSHD-Dienst durch dieses Skript neu gestartet.
    #!/bin/bash
    set -e
    
    SSHD_CONFIG_FILE=/etc/ssh/sshd_config
    # -c: count the matches
    # -q: don't print to console
    # -i: sshd_config keywords are case insensitive.
    if [[ "$(grep -ci '^LoginGraceTime' $SSHD_CONFIG_FILE)" -eq 0 ]]; then
        echo "LoginGraceTime 0" >> "$SSHD_CONFIG_FILE"
        echo "Set the LoginGraceTime to 0 in $SSHD_CONFIG_FILE"
    else
        sed -i 's/^LoginGraceTime.*$/LoginGraceTime 0/' /etc/ssh/sshd_config
        echo "Changed the LoginGraceTime to 0 in $SSHD_CONFIG_FILE"
    fi
    # Restart the sshd service to apply the new config.
    systemctl restart sshd
        
  4. Achten Sie schließlich auf ungewöhnliche Netzwerkaktivitäten im Zusammenhang mit SSH-Servern.
Kritisch CVE-2024-6387

GCP-2024-021

Veröffentlicht: 03.04.2024
Beschreibung Schweregrad Hinweise

Compute Engine ist nicht von CVE-2024-3094 betroffen. Diese Sicherheitslücke betrifft die Versionen 5.6.0 und 5.6.1 des xz-utils-Pakets in der liblzma-Bibliothek und könnte zu einer Kompromittierung des OpenSSH-Dienstprogramms führen.

Wie gehe ich am besten vor?

Von Compute Engine unterstützte und angebotene öffentliche Images sind von dieser CVE nicht betroffen. Wenn Sie öffentliche Compute Engine-Images für Ihre VMs verwenden, ist keine Aktion erforderlich.

Sie sind möglicherweise gefährdet, wenn Sie ein benutzerdefiniertes Image erstellt haben, in dem die Versionen 5.6.0 und 5.6.1 des xz-utils-Pakets verwendet wurden, z. B. bei den folgenden Betriebssystemen:

Um dieses Risiko zu minimieren, beenden Sie alle VMs, die diese oder andere Betriebssysteme verwenden, die möglicherweise von den betroffenen Betriebssystemen verwendet wurden. Wenn Sie VMs haben, die aus benutzerdefinierten Images anderer Betriebssysteme erstellt wurden, wenden Sie sich an Ihren Betriebssystemanbieter, um zu prüfen, ob Ihre VMs betroffen sind.

Welche Sicherheitslücken werden behoben?

CVE-2024-3094

Mittel CVE-2024-3094

GCP-2024-001

Veröffentlicht: 09.01.2024
Beschreibung Schweregrad Hinweise

In der TianoCore EDK II UEFI-Firmware wurden mehrere Sicherheitslücken entdeckt. Diese Firmware wird in Google Compute Engine-VMs verwendet. Wenn die Sicherheitslücken ausgenutzt werden, könnte Secure Boot umgangen werden, was zu falschen Bewertungen im Secure Boot-Prozess führen würde, auch bei der Verwendung von Shielded VMs.

Wie gehe ich am besten vor?

Sie müssen nichts weiter tun. Google hat diese Sicherheitslücke in Compute Engine behoben und alle VMs sind vor dieser Sicherheitslücke geschützt.

Welche Sicherheitslücken werden mit diesem Patch behoben?

Dieser Patch dient zur Minimierung der Auswirkungen folgender Sicherheitslücken:

  • CVE-2022-36763
  • CVE-2022-36764
  • CVE-2022-36765
Mittel

GCP-2023-44

Veröffentlicht: 15.11.2023
Beschreibung Schweregrad Hinweise

Am 14. November hat AMD mehrere Sicherheitslücken offengelegt, die sich auf verschiedene AMD-Server-CPUs auswirken. Die Sicherheitslücken betreffen insbesondere EPYC-Server-CPUs mit Zen-Core der 2. Generation („Rome“), der 3. Generation („Milan“) und der 4. Generation („Genoa“).

Google hat Korrekturen für betroffene Assets, einschließlich Google Cloud, vorgenommen, um Kunden zu schützen. Derzeit gibt es keine Hinweise auf eine Ausnutzung oder entsprechende Meldungen an Google.

Wie gehe ich am besten vor?

Auf Kundenseite sind keine Maßnahmen erforderlich.

Die Korrekturen wurden bereits auf die Google-Serverflotte für Google Cloudangewendet, einschließlich Google Compute Engine.

Welche Sicherheitslücken werden mit diesem Patch behoben?

Dieser Patch dient zur Minimierung der Auswirkungen folgender Sicherheitslücken:

  • CVE-2022-23820
  • CVE-2021-46774
  • CVE-2023-20533
  • CVE-2023-20519
  • CVE-2023-20592
  • CVE-2023-20566
  • CVE-2023-20521
  • CVE-2021-46766
  • CVE-2022-23830
  • CVE-2023-20526
  • CVE-2021-26345

Weitere Informationen finden Sie in der Sicherheitsempfehlung von AMD AMD-SN-3005: „AMD INVD Instruction Security Notice“, auch unter dem Namen „CacheWarp“ veröffentlicht, und AMD-SN-3002: „AMD Server Vulnerabilities – November 2023“.

Mittel

GCP-2023-004

Veröffentlicht: 26.04.2023
Beschreibung Schweregrad Hinweise

Im Trusted Platform Module (TPM) 2.0 wurden zwei Sicherheitslücken entdeckt (CVE-2023-1017 und CVE-2023-1018).

Die Sicherheitslücken hätten es einem versierten Angreifer ermöglicht, einen 2-Byte-Lese-/Schreibvorgang außerhalb des zulässigen Bereichs auf bestimmten Compute Engine-VMs auszunutzen.

Wie gehe ich am besten vor?

Ein Patch wurde automatisch auf alle anfälligen VMs angewendet. Auf Kundenseite sind keine Maßnahmen erforderlich.

Welche Sicherheitslücken werden mit diesem Patch behoben?

Dieser Patch dient zur Minimierung der Auswirkungen folgender Sicherheitslücken:

CVE-2023-1017

Bei CVE-2023-2017 konnte ein Pufferüberlauf in der vTPM-Parameterentschlüsselungsroutine ausgelöst werden. Ein lokaler Angreifer, der auf einer anfälligen VM ausgeführt wird, könnte dies nutzen, um einen Denial-of-Service auszulösen oder möglicherweise beliebigen Code im vTPM-Kontext auszuführen.

CVE-2023-1018

Bei CVE-2023-2018 gab es einen Lesevorgang außerhalb des Bereichs in der vTPM-Parameterentschlüsselungsroutine. Ein lokaler Angreifer, der auf einer anfälligen VM ausgeführt wird, könnte dies verwenden, um indirekt begrenzte Daten aus dem vTPM-Kontext zu stehlen.

Mittel

GCP-2021-026

Veröffentlicht: 14.12.2021
Beschreibung Schweregrad Hinweise

Das Apache Log4j-Dienstprogramm wird häufig für Logging-Anfragen verwendet. Am 9. Dezember 2021 wurde eine Sicherheitslücke gemeldet, bei der ein System mit Apache Log4j-Version 2.14.1 oder niedriger manipuliert werden konnte und Angreifer einen beliebigen Code ausführen konnten.

Am 10. Dezember 2021 hat NIST eine kritische Benachrichtigung zu allgemeinen Sicherheitslücken und Bedrohungen (CVE-2021-44228) veröffentlicht. Insbesondere schützen die Funktionen von Java Naming Directory Interface (JNDI), die in der Konfiguration sowie in Logeinträgen und Parametern verwendet werden, nicht durch Angreifer kontrollierte LDAP- und anderen JNDI-Endpunkte. Ein Angreifer, der Logeinträge oder Lognachrichten-Parameter steuern kann, kann beliebigen Code ausführen, der von Remote-Servern geladen wird, wenn „Message Lookup Substitution“ aktiviert ist.

Wie gehe ich am besten vor?

  • M4CE v4.x:Das Migrate for Compute Engine-Team (M4CE) hat am 13. Dezember 2021 eine neue Version bereitgestellt. Projektmanager müssen die vorhandene Bereitstellung durch die neue Version ersetzen, die den In-Cloud-M4CE-Manager und das M4CE-Backend „on premises“ enthält. Weitere Informationen zur Bereitstellung von Version 4.11 finden Sie in der Anleitung.
  • M2VMs v5.x:M2VMs v5.0 und höher wurden korrigiert und es sind keine Maßnahmen erforderlich.
Kritisch

GCP-2021-001

Veröffentlicht: 28.01.2021
Beschreibung Schweregrad Hinweise

Im Linux-Dienstprogramm sudo wurde eine Sicherheitslücke entdeckt, die in CVE-2021-3156 beschrieben wurde. Dies könnte einem Angreifer mit nicht privilegierten lokalen Shell-Zugriff auf einem System mit installiertem sudo ermöglichen, seine Berechtigungen auf das Root-System auszuweiten.

Auswirkungen auf Compute Engine

Die zugrunde liegende Infrastruktur, auf der Compute Engine ausgeführt wird, ist von dieser Sicherheitslücke nicht betroffen. Compute Engine-VMs, auf denen Linux ausgeführt wird, sollten ihr Gastbetriebssystem aktualisieren. Wenn Sie beispielsweise Container-Optimized OS verwenden, empfehlen wir Ihnen, auf eines der folgenden Images zu aktualisieren: cos-85-13310-1209-7, cos-81-12871-1245-6, cos-dev-89-16091-0-0 oder höher.

Keine

Veröffentlichungsdatum: 27.08.2020

Beschreibung Schweregrad Hinweise

Eclypsium hat das folgende CVE offengelegt: CVE-2020-10713.

Sicherheitslücken

Als Reaktion auf den ursprünglichen Bericht zu Sicherheitslücken wurde der GRUB2-Code einer zusätzlichen Prüfung unterzogen und die folgenden zusätzlichen Sicherheitslücken wurden von Canonical entdeckt:

Diese Sicherheitslücken, die zusammen als BootHole bezeichnet werden, ermöglichen es Angreifern mit Administratorberechtigungen, unsignierte Binärdateien zu laden und so die Durchsetzung von Secure Boot zu deaktivieren.

Auswirkungen auf Compute Engine

Die Hostinfrastruktur, auf der Compute Engine ausgeführt wird, ist vor bekannten Angriffen geschützt.

Compute Engine-Kunden, die Secure Boot verwenden, wird empfohlen, die Gastbetriebssysteme auf ihren Instanzen zu aktualisieren, um die Möglichkeit einer Ausnutzung in ihren Gastumgebungen zu verhindern. Weitere Informationen finden Sie in den Empfehlungen Ihres Gastbetriebssystemanbieters.

Gepatchte Images und Anbieterressourcen

Sobald die jeweiligen Betriebssystemanbieter Patchinformationen zur Verfügung gestellt haben, finden Sie auf dieser Seite entsprechende Links. Frühere Versionen dieser öffentlichen Images enthalten diese Patches nicht und können die Wirkung potenzieller Angriffe nicht abschwächen:

  • Projekt centos-cloud: CentOS-Patchinformationen
    • centos-7-v20200811
    • centos-8-v20200811
  • Projekt cos-cloud:
    • cos-77-12371-1072-0
    • cos-81-12871-1185-0
    • cos-rc-85-13310-1028-0
    • cos-dev-86-15103-0-0

    Wenn Sie COS über einen verwalteten Dienst (z.B. GKE) verwenden, folgen Sie der Anleitung für diesen Dienst, um Updates anzuwenden.

  • Projekt debian-cloud: DSA-4753
    • debian-10-buster-v20200805
  • Projekt coreos-cloud:
    • coreos-alpha-2163-2-1-v20190617
    • coreos-beta-2135-3-1-v20190617
    • coreos-stable-2079-6-0-v20190617
  • Projekt rhel-cloud/rhel-sap-cloud: Red Hat Vulnerability Response
    • rhel-7-v20200811
    • rhel-7-4-sap-v20200811
    • rhel-7-6-sap-v20200811
    • rhel-7-7-sap-v20200811
    • rhel-8-v20200811
  • Projekt suse-cloud/suse-sap-cloud:: SUSE KB
    • sles-12-sp5-v20200813
    • sles-15-sp2-v20200804
    • sles-12-sp4-sap-v20200804
    • sles-12-sp5-sap-v20200813
    • sles-15-sap-v20200803
    • sles-15-sp1-sap-v20200803
    • Sles-15-sp2-sap-v20200804
  • Projekt ubuntu-os-cloud: Ubuntu-Wiki
    • ubuntu-1604-xenial-v20200729
    • ubuntu-1804-bionic-v20200729
    • ubuntu-2004-focal-v20200729
Hoch

Veröffentlichungsdatum: 19.06.2020

Beschreibung Schweregrad Hinweise

VMs, für die OS Login aktiviert ist, sind potenziell anfällig für Sicherheitslücken in Bezug auf die Rechteausweitung. Durch diese Sicherheitslücken bekommen Nutzer, die OS Login-Berechtigungen ohne Administratorzugriff erhalten haben, die Möglichkeit, zum Root-Zugriff in der VM zu eskalieren.

Sicherheitslücken

Für Compute Engine-Images wurden die folgenden drei Sicherheitslücken identifiziert, die auf zu permissiven Standardgruppenmitgliedschaften beruhen:

  • CVE-2020-8903: Mit dem Nutzer adm können Sie die DHCP-XID nutzen, um Administratorberechtigungen zu erhalten.
  • CVE-2020-8907: Mit dem Nutzer docker können Sie das Dateisystem des Hostbetriebssystems bereitstellen und ändern, um Administratorberechtigungen zu erhalten.
  • CVE-2020-8933: Wenn Sie den Nutzer lxd verwenden, können Sie Dateisysteme des Host-Betriebssystems anhängen und Administratorberechtigungen erhalten.

Gepatchte Images und Korrekturen

Alle öffentlichen Compute Engine-Images, die nach dem v20200506 erstellt wurden, sind gepatcht.

Wenn Sie dieses Problem beheben möchten, ohne auf eine neuere Version Ihres Images zu aktualisieren, können Sie die Datei /etc/security/group.conf bearbeiten und die Nutzer adm, lxd und docker aus dem Standardeintrag für OS Login entfernen.

Hoch

Veröffentlichungsdatum: 21.01.2020

Beschreibung Schweregrad Hinweise

Microsoft hat die folgende Sicherheitslücke offengelegt:

  • CVE-2020-0601: Diese Sicherheitslücke wird auch als Windows Crypto API-Spoofing-Sicherheitslücke bezeichnet und könnte dazu genutzt werden, bösartige ausführbare Dateien vertrauenswürdig zu machen oder dem Angreifer Man-in-the-Middle-Angriffe zu ermöglichen und vertrauliche Informationen über Nutzerverbindungen mit der betroffenen Software zu entschlüsseln.

Auswirkungen auf Compute Engine

Die zugrunde liegende Infrastruktur, auf der Compute Engine ausgeführt wird, ist von dieser Sicherheitslücke nicht betroffen. Sofern Sie Windows Server nicht auf Ihrer Compute Engine-VM ausführen, sind keine weiteren Maßnahmen erforderlich. Kunden, die Compute Engine-VMs mit Windows Server verwenden, sollten dafür sorgen, dass ihre Instanzen den neuesten Windows-Patch haben.

Gepatchte Images und Anbieterressourcen

Frühere Versionen der öffentlichen Windows-Images enthalten die folgenden Patches nicht und können die Wirkung potenzieller Angriffe nicht abschwächen:

  • Projekte windows-cloud und windows-sql-cloud
    • Alle öffentlichen Images von Windows Server und SQL Server ab v20200114
Mittel

Veröffentlichungsdatum: 12.11.2019

Beschreibung Schweregrad Hinweise

Die folgenden CVEs (Common Vulnerabilities and Exposures) wurden von Intel offengelegt:

  • CVE-2019-11135: Diese CVE-Sicherheitslücke wird auch als TSX Async Abort (TAA) bezeichnet. TAA bietet einen anderen Pfad für die Daten-Exfiltration mit denselben mikroarchitektonischen Datenstrukturen, die auch durch Microarchitectural Data Sampling (MDS) gefährdet waren.
  • CVE-2018-12207: Diese CVE-Sicherheitslücke wird auch als „Machine Check Error on Page Size Change“ bezeichnet. Dies ist eine DoS-Sicherheitslücke (Denial of Service) auf VM-Hosts, über die ein schädlicher Gast einen ungeschützten Host zum Absturz bringen kann.

Auswirkungen auf Compute Engine

CVE-2019-11135

Die Hostinfrastruktur, auf der Compute Engine ausgeführt wird, dient dazu, Arbeitslasten von Kunden voneinander zu isolieren. Sofern Sie keinen nicht vertrauenswürdigen Code auf N2-, C2- oder M2-VMs ausführen, sind keine weiteren Gegenmaßnahmen erforderlich.

N2-, C2- oder M2-Kunden, die auf virtuellen Maschinen von Compute Engine für ihre eigenen Dienste mit mehreren Mandanten nicht vertrauenswürdigen Code ausführen, sollten ihre VMs beenden und wieder starten, um zu gewährleisten, dass die neuesten Sicherheitsmaßnahmen vorliegen. Ein Neustart ohne Stoppen/Starten reicht nicht aus. In dieser Anleitung wird davon ausgegangen, dass Sie bereits zuvor veröffentlichte Updates angewendet haben, die die MDS-Sicherheitslücke schließen. Falls nicht, folgen Sie der Anleitung, um die entsprechenden Updates anzuwenden.

Für Kunden, die N1-Maschinentypen verwenden, sind keine Maßnahmen erforderlich, da diese Sicherheitslücke keine neuen Risiken birgt, die über die zuvor offengelegten MDS-Sicherheitslücken hinausgehen.

CVE-2018-12207

Die Hostinfrastruktur, auf der Compute Engine ausgeführt wird, ist vor dieser Sicherheitslücke geschützt. Es sind keine weiteren Maßnahmen erforderlich.

Mittel

Veröffentlichungsdatum: 18.06.2019

Zuletzt aktualisiert: 25.06.2019, 6:30 Uhr (UTC-8)

Beschreibung Schweregrad Hinweise

Netflix hat vor Kurzem drei TCP-Sicherheitslücken in Linux-Kernels offengelegt:

Diese CVEs (Common Vulnerabilities and Exposures) werden zusammen als NFLX-2019-001 bezeichnet.

Auswirkungen auf Compute Engine

Die Infrastruktur, auf der Compute Engine gehostet wird, ist vor dieser Sicherheitslücke geschützt.

Compute Engine-VMs sind für diesen DoS-Angriff nur dann anfällig, wenn auf ihnen nicht gepatchte Linux-Betriebssysteme ausgeführt werden und sie nicht vertrauenswürdigen Netzwerktraffic senden oder empfangen. Aktualisieren Sie diese VM-Instanzen so bald wie möglich, wenn Patches für die Betriebssysteme dieser Instanzen verfügbar sind.

Auf Load-Balancern, die TCP-Verbindungen schließen, wurde diese Sicherheitslücke geschlossen. Compute Engine-Instanzen, die über diese Load-Balancer ausschließlich nicht vertrauenswürdigen Traffic empfangen, sind nicht anfällig. Dazu zählen HTTP-Load-Balancer, SSL-Proxy-Load-Balancer und TCP-Proxy-Load-Balancer.

Netzwerk-Load-Balancer und interne Load-Balancer schließen keine TCP-Verbindungen. Nicht gepatchte Compute Engine-Instanzen, die nicht vertrauenswürdigen Traffic über diese Load-Balancer empfangen, sind anfällig.

Gepatchte Images und Anbieterressourcen

Sobald die jeweiligen Betriebssystemanbieter Patchinformationen zur Verfügung gestellt haben, finden Sie auf dieser Seite entsprechende Links sowie den aktuellen Status zu diesen CVEs. Frühere Versionen dieser öffentlichen Images enthalten diese Patches nicht und können die Wirkung potenzieller Angriffe nicht abschwächen:

  • Projekt debian-cloud:
    • debian-9-stretch-v20190618
  • Projekt centos-cloud:
    • centos-6-v20190619
    • centos-7-v20190619
  • Projekt cos-cloud:
    • cos-dev-77-12293-0-0
    • cos-beta-76-12239-21-0
    • cos-stable-75-12105-77-0
    • cos-73-11647-217-0
    • cos-69-10895-277-0
  • Projekt coreos-cloud:
    • coreos-alpha-2163-2-1-v20190617
    • coreos-beta-2135-3-1-v20190617
    • coreos-stable-2079-6-0-v20190617
  • Projekt rhel-cloud:
    • rhel-6-v20190618
    • rhel-7-v20190618
    • rhel-8-v20190618
  • Projekt rhel-sap-cloud:
    • rhel-7-4-sap-v20190618
    • rhel-7-6-sap-v20190618
  • Projekt suse-cloud:
    • sles-12-sp4-v20190617
    • sles-15-v20190617
  • Projekt suse-sap-cloud:
    • sles-12-sp1-sap-v20190617
    • sles-12-sp2-sap-v20190617
    • sles-12-sp3-sap-v20190617
    • sles-12-sp4-sap-v20190617
    • sles-15-sap-v20190617
  • Projekt ubuntu-cloud:
    • ubuntu-1604-xenial-v20190617
    • ubuntu-1804-bionic-v20190617
    • ubuntu-1810-cosmic-v20190618
    • ubuntu-1904-disco-v20190619
    • ubuntu-minimal-1604-xenial-v20190618
    • ubuntu-minimal-1804-bionic-v20190617
    • ubuntu-minimal-1810-cosmic-v20190618
    • ubuntu-minimal-1904-disco-v20190618
Mittel

Veröffentlichungsdatum: 14.05.2019

Zuletzt aktualisiert: 20.05.2019, 17:00 Uhr (UTC-8)

Beschreibung Schweregrad Hinweise

Die folgenden CVEs (Common Vulnerabilities and Exposures) wurden von Intel offengelegt:

Diese CVEs werden zusammen als Microarchitectural Data Sampling (MDS) bezeichnet. Diese Sicherheitslücken bringen das Risiko mit sich, dass Daten Angriffen ausgesetzt sind, die durch Interaktion einer spekulativen Ausführung mit dem mikroarchitektonischen Status erfolgen.

Auswirkungen auf Compute Engine

Die Hostinfrastruktur, auf der Compute Engine ausgeführt wird, dient dazu, Arbeitslasten von Kunden voneinander zu isolieren. Sofern Sie keinen nicht vertrauenswürdigen Code auf den VMs ausführen, sind keine weiteren Gegenmaßnahmen erforderlich.

Kunden, die auf virtuellen Maschinen von Compute Engine für ihre eigenen Dienste mit mehreren Mandanten nicht vertrauenswürdigen Code ausführen, sollten sich an die empfohlenen Maßnahmen zur Risikominderung halten, die der Anbieter ihres Gastbetriebssystems vorsieht. Diese Gegenmaßnahmen umfassen unter Umständen den Einsatz von Microcode-Funktionen von Intel. Für die neue Flush-Funktionalität haben wir einen Zugang für Gäste eingerichtet. Im Folgenden finden Sie eine Zusammenfassung der Schritte, die als Abhilfe für übliche Gäste-Images zur Verfügung stehen.

Gepatchte Images und Anbieterressourcen

Sobald die jeweiligen Betriebssystemanbieter Patchinformationen zur Verfügung gestellt haben, finden Sie auf dieser Seite entsprechende Links sowie den aktuellen Status zu diesen CVEs. Verwenden Sie diese Images, um VM-Instanzen neu zu erstellen. Frühere Versionen dieser öffentlichen Images enthalten diese Patches nicht und können die Wirkung potenzieller Angriffe nicht abschwächen.

  • Projekt centos-cloud: CESA-2019:1169, CESA-2019:1168
    • centos-6-v20190515
    • centos-7-v20190515
  • Projekt coreos-cloud: MDS-Strategien zur Risikominderung für CoreOS Container Linux
    • coreos-stable-2079-4-0-v20190515
    • coreos-beta-2107-3-0-v20190515
    • coreos-alpha-2135-1-0-v20190515
  • Projekt cos-cloud
    • cos-69-10895-242-0
    • cos-73-11647-182-0
  • Projekt debian-cloud: DSA-4444
    • debian-9-stretch-v20190514
  • Projekt rhel-cloud: Informationsartikel zu Red Hat MDS
    • rhel-6-v20190515
    • rhel-7-v20190517
    • rhel-8-v20190515
  • Projekt rhel-sap-cloud: Informationsartikel zu Red Hat MDS
    • rhel-7-4-sap-v20190515
    • rhel-7-6-sap-v20190517
  • Projekt suse-cloud: SUSE MDS KB
    • sles-12-sp4-v20190520
    • sles-15-v20190520
  • Projekt suse-sap-cloud
    • sles-12-sp4-sap-v20190520
    • sles-15-sap-v20190520
  • Projekt ubuntu-os-cloud: Wiki zu Ubuntu MDS
    • ubuntu-1404-trusty-v20190514
    • ubuntu-1604-xenial-v20190514
    • ubuntu-1804-bionic-v20190514
    • ubuntu-1810-cosmic-v20190514
    • ubuntu-1904-disco-v20190514
    • ubuntu-minimal-1604-xenial-v20190514
    • ubuntu-minimal-1804-bionic-v20190514
    • ubuntu-minimal-1810-cosmic-v20190514
    • ubuntu-minimal-1904-disco-v20190514
  • Projekte windows-cloud und windows-sql-cloud: Microsoft ADV190013
    • Alle öffentlichen Images von Windows Server und SQL Server mit der Versionsnummer v20190514.
  • Projekt gce-uefi-images
    • centos-7-v20190515
    • cos-69-10895-242-0
    • cos-73-11647-182-0
    • rhel-7-v20190517
    • ubuntu-1804-bionic-v20190514
    • Alle öffentlichen Images von Windows Server mit der Versionsnummer v20190514.

Container-Optimized OS

Wenn Sie als Gästebetriebssystem Container-Optimized OS nutzen und auf den virtuellen Maschinen nicht vertrauenswürdige Arbeitslasten mit mehreren Mandanten ausführen, empfehlen wir folgendes Vorgehen:

  1. Deaktivieren Sie das Hyper-Threading, indem Sie in der Kernel-Befehlszeile nosmt festlegen.

    Bei bestehenden COS-VMs können Sie grub.cfg wie folgt modifizieren, um die Option nosmt festzulegen und das System anschließend neu zu starten:

    # Run as root:
    dir="$(mktemp -d)"
    mount /dev/sda12 "${dir}"
    sed -i -e "s|cros_efi|cros_efi nosmt|g" "${dir}/efi/boot/grub.cfg"
    umount "${dir}"
    rmdir "${dir}"
    
    reboot

    Zur Vereinfachung können Sie das folgende Skript ausführen, um dasselbe Ergebnis zu erzielen wie mit den oben aufgeführten Befehlen. Wir empfehlen, dieses Skript in Ihre Cloud-Konfiguration, Startskripts oder Instanzvorlagen aufzunehmen, damit diese neuen Parameter für neue VMs verwendet werden. Unten ist ein Beispiel für eine Cloud-Konfiguration aufgeführt, die dieses Skript ausführt.

    Warnung: Dieser Befehl führt beim erstmaligen Ausführen dazu, dass die Instanz sofort neu gestartet wird. Wird der Befehl anschließend mit einer Instanz wiederholt, bei der das Hyper-Threading bereits deaktiviert ist, hat dies keine Auswirkungen.

    # Run as root
    /bin/bash <(curl -s https://storage.googleapis.com/cos-tools/scripts/disable_smt.sh)
    

    Als Bestandteil der Cloud-Konfiguration sieht dies so aus:

    #cloud-config
    
    bootcmd:
    - /bin/bash -c "/bin/bash <(curl -s https://storage.googleapis.com/cos-tools/scripts/disable_smt.sh)"
    

    Sehen Sie sich die Ausgabe der Dateien /sys/devices/system/cpu/smt/active und /sys/devices/system/cpu/smt/control an, um zu überprüfen, ob das Hyper-Threading deaktiviert ist. Wird 0 für active und off für control zurückgegeben, ist das Hyper-Threading deaktiviert:

    cat /sys/devices/system/cpu/smt/active
    cat /sys/devices/system/cpu/smt/control
    

    Hinweis: Falls Sie auf Ihrer Instanz UEFI Secure Boot aktiviert haben, müssen Sie die Instanz noch einmal mit deaktiviertem UEFI Secure Boot erstellen, den oben aufgeführten Befehl bei deaktiviertem UEFI Secure Boot ausführen und dann UEFI Secure Boot auf der neuen Instanz aktivieren.

  2. Verwenden Sie die neue Version des COS-Images.

    Zusätzlich zum Deaktivieren des Hyper-Threading wie oben beschrieben sollten Sie auch die Instanzen neu erstellen, und zwar mit den oben aufgeführten aktualisierten Images oder neueren Versionen der Images mit Container-Optimized OS (sofern verfügbar), damit dort, wo die Sicherheitslücke besteht, ein vollständiger Schutz hergestellt wird.

Mittel

Veröffentlichungsdatum: 14.08.2018

Zuletzt aktualisiert: 20.08.2018, 17:00 Uhr (UTC -8)

Beschreibung Schweregrad Hinweise

Beschreibung

Die folgenden CVEs (Common Vulnerabilities and Exposures) wurden von Intel offengelegt:

Diese CVEs werden zusammenfassend als "L1 Terminal Fault (L1TF)" bezeichnet.

Durch diese L1TF-Sicherheitslücken wird die spekulative Ausführung des Prozessors dazu genutzt, Angriffe auf die Konfiguration von Datenstrukturen auf Prozessorebene durchzuführen. "L1" bezeichnet den Level-1-Datencache (L1D), eine kleine On-Core-Ressource für die Beschleunigung des Speicherzugriffs.

Weitere Informationen zu diesen Sicherheitslücken und den entsprechenden Gegenmaßnahmen in Compute Engine erhalten Sie im Google Cloud Blogpost.

Auswirkungen auf Compute Engine

Die Hostinfrastruktur, auf der Compute Engine ausgeführt wird, und die die Arbeitslasten von Kunden voneinander isoliert, ist vor bekannten Angriffen geschützt.

Kunden von Compute Engine wird empfohlen, ihre Images zu aktualisieren, um mögliche indirekte Angriffe auf ihre Gastumgebungen zu verhindern. Dies ist insbesondere für Kunden wichtig, die ihre eigenen mandantenfähigen Dienste auf virtuellen Maschinen in Compute Engine ausführen.

Compute Engine-Kunden können die Gastbetriebssysteme auf ihren Instanzen über eine der folgenden Optionen aktualisieren:

  • Verwenden Sie gepatchte öffentliche Images, um vorhandene VM-Instanzen neu zu erstellen.
  • Installieren Sie auf vorhandenen Instanzen vom Betriebssystemanbieter bereitgestellte Patches und starten Sie die gepatchten Instanzen neu.

Gepatchte Images und Anbieterressourcen

Sobald die jeweiligen Betriebssystemanbieter Patchinformationen zur Verfügung gestellt haben, finden Sie auf dieser Seite entsprechende Links sowie den aktuellen Status zu den beiden CVEs. Verwenden Sie diese Images, um Ihre VM-Instanzen neu zu erstellen. Frühere Versionen dieser öffentlichen Images enthalten diese Patches nicht und können die Wirkung potenzieller Angriffe nicht abschwächen.

  • Projekt centos-cloud:
    • centos-7-v20180815
    • centos-6-v20180815
  • Projekt coreos-cloud:
    • coreos-stable-1800-7-0-v20180816
    • coreos-beta-1855-2-0-v20180816
    • coreos-alpha-1871-0-0-v20180816
  • Projekt cos-cloud:
    • cos-stable-66-10452-110-0
    • cos-stable-67-10575-66-0
    • cos-beta-68-10718-81-0
    • cos-dev-69-10895-23-0
  • Projekt debian-cloud:
    • debian-9-stretch-v20180820
  • Projekt rhel-cloud:
    • rhel-7-v20180814
    • rhel-6-v20180814
  • Projekt rhel-sap-cloud:
    • rhel-7-sap-apps-v20180814
    • rhel-7-sap-hana-v20180814
  • Projekt suse-cloud:
    • sles-15-v20180816
    • sles-12-sp3-v20180814
    • sles-11-sp4-v20180816
  • Projekt suse-sap-cloud:
    • sles-15-sap-v20180816
    • sles-12-sp3-sap-v20180814
    • sles-12-sp2-sap-v20180816
  • Projekt ubuntu-os-cloud:
    • ubuntu-1804-bionic-v20180814
    • ubuntu-1604-xenial-v20180814
    • ubuntu-1404-trusty-v20180814
    • ubuntu-minimal-1804-bionic-v20180814
    • ubuntu-minimal-1604-xenial-v20180814
  • Projekte windows-cloud gce-uefi-images und windows-sql-cloud:
    • Alle öffentlichen Images von Windows Server und SQL Server mit der Versionsnummer -v201800814 und höher enthalten Patches.
Hoch

Veröffentlichungsdatum: 06.08.2018

Zuletzt aktualisiert: 05.09.2018, 17:00 Uhr (UTC -8)

Beschreibung Schweregrad Hinweise

Aktualisierung vom 05.09.2018

CVE-2018-5391 wurde am 14.08.2018 von US-CERT offengelegt. Wie bei CVE-2018-5390 wird eine Sicherheitslücke bei Netzwerken auf Kernel-Ebene beschrieben, durch die die Effektivität von DoS-Angriffen (Denial of Service) auf anfällige Systeme erhöht wird. Der Hauptunterschied besteht darin, dass CVE-2018-5391 über IP-Verbindungen ausgenutzt werden kann. Wir haben dieses Bulletin so aktualisiert, dass beide Sicherheitslücken angesprochen werden.

Beschreibung

CVE-2018-5390 ("SegmentSmack") beschreibt eine Netzwerk-Sicherheitslücke auf Kernelebene, durch die die Effektivität von DoS-Angriffen (Denial of Service) über TCP-Verbindungen auf anfällige Systeme erhöht wird.

CVE-2018-5391 ("FragmentSmack") beschreibt eine Netzwerk-Sicherheitslücke auf Kernelebene, durch die die Effektivität von DoS-Angriffen (Denial of Service) über IP-Verbindungen auf anfällige Systeme erhöht wird.

Auswirkungen auf Compute Engine

Für die Hostinfrastruktur, auf der Compute Engine-VMs ausgeführt werden, besteht kein Risiko. Die Netzwerkinfrastruktur, die den Traffic von und zu Compute Engine-VMs handhabt, ist gegen diese Sicherheitslücke geschützt. Compute Engine-VMs, die nicht vertrauenswürdigen Traffic ausschließlich über HTTP(S)-, SSL- oder TCP-Load-Balancer senden/empfangen, sind gegen diese Sicherheitslücke geschützt.

Compute Engine-VMs sind für diesen DoS-Angriff nur dann anfällig, wenn auf ihnen nicht gepatchte Betriebssysteme ausgeführt werden und sie nicht vertrauenswürdigen Netzwerktraffic direkt oder über Netzwerk-Load-Balancer senden/empfangen.

Aktualisieren Sie Ihre VM-Instanzen so bald wie möglich, wenn Patches für ihre Betriebssysteme verfügbar sind.

Kunden von Compute Engine können die Gastbetriebssysteme auf ihren Instanzen über eine der folgenden Optionen aktualisieren:

  • Verwenden Sie gepatchte öffentliche Images, um vorhandene VM-Instanzen neu zu erstellen. Unten finden Sie eine Liste der gepatchten öffentlichen Images.
  • Installieren Sie auf vorhandenen Instanzen vom Betriebssystemanbieter bereitgestellte Patches und starten Sie die gepatchten Instanzen neu.

Gepatchte Images und Anbieterressourcen

Sobald die jeweiligen Betriebssystemanbieter Patchinformationen zur Verfügung gestellt haben, finden Sie auf dieser Seite entsprechende Links.

  • Projekt centos-cloud (nur CVE-2018-5390):
    • centos-7-v20180815
    • centos-6-v20180815
  • Projekt coreos-cloud (CVE-2018-5390 und CVE-2018-5391):
    • coreos-stable-1800-7-0-v20180816
    • coreos-beta-1855-2-0-v20180816
    • coreos-alpha-1871-0-0-v20180816
  • Projekt cos-cloud (CVE-2018-5390 und CVE-2018-5391):
    • cos-stable-65-10323-98-0
    • cos-stable-66-10452-109-0
    • cos-stable-67-10575-65-0
    • cos-beta-68-10718-76-0
    • cos-dev-69-10895-16-0
  • Projekt debian-cloud (CVE-2018-5390 und CVE-2018-5391):
    • debian-9-stretch-v20180814
  • Projekt rhel-cloud (nur CVE-2018-5390):
    • rhel-7-v20180814
    • rhel-6-v20180814
  • Projekt suse-cloud (CVE-2018-5390 und CVE-2018-5391):
    • sles-15-v20180816
    • sles-12-sp3-v20180814
  • Projekt suse-sap-cloud (CVE-2018-5390 und CVE-2018-5391):
    • sles-15-sap-v20180816
    • sles-12-sp3-sap-v20180814
    • sles-12-sp2-sap-v20180816
  • Projekt ubuntu-os-cloud (CVE-2018-5390 und CVE-2018-5391):
    • ubuntu-1804-bionic-v20180814
    • ubuntu-1604-xenial-v20180814
    • ubuntu-1404-trusty-v20180814
    • ubuntu-minimal-1804-bionic-v20180814
    • ubuntu-minimal-1604-xenial-v20180814
Hoch

Veröffentlichungsdatum: 03.01.2018

Zuletzt aktualisiert: 21.05.2018, 15:00 Uhr (UTC -8)

Beschreibung Schweregrad Hinweise

Aktualisierung vom 21.05.2018

Die Sicherheitslücken CVE-2018-3640 und CVE-2018-3639, Varianten 3a bzw. 4, wurden von Intel offengelegt. Wie bei den ersten drei Varianten von Spectre und Meltdown ist die Infrastruktur geschützt, auf der Compute Engine-VM-Instanzen ausgeführt werden, und VM-Instanzen von Kunden sind isoliert und voreinander geschützt. Darüber hinaus plant das Team von Compute Engine, Microcode-Patches von Intel in unserer Infrastruktur zu implementieren. Kunden, die mandantenfähige oder nicht vertrauenswürdige Arbeitslasten in einer einzelnen VM-Instanz ausführen, können dadurch innerhalb der VM zusätzliche Gegenmaßnahmen ergreifen, wenn die Betriebssystemanbieter solche Maßnahmen anbieten. Das Team von Compute Engine wird die Microcode-Patches implementieren, sobald sie von Intel zertifiziert und von Compute Engine für unsere Produktionsumgebung getestet und qualifiziert wurden. Auf dieser Seite finden Sie genaue Zeitpläne und Neuigkeiten, sobald diese vorliegen.

Beschreibung

Diese CVEs sind Varianten einer neuen Angriffsklasse, die die in vielen Prozessoren verfügbare Technologie der spekulativen Ausführung ausnutzen. Bei dieser Klasse von Angriffen kann es unter verschiedenen Umständen zu einem unberechtigten Lesezugriff auf Speicherdaten kommen.

Compute Engine nutzte die Live-Migrationstechnologie für virtuelle Maschinen, um Hostsystem- und Hypervisor-Updates ohne Beteiligung der Nutzer, ohne erzwungene Wartungsfenster und ohne erforderliche Massenneustarts durchzuführen. Als Schutz vor dieser neuen Angriffsklasse müssen jedoch alle Gastbetriebssysteme und -versionen gepatcht werden, unabhängig davon, wo diese Systeme ausgeführt werden.

Der Project Zero-Blogpost enthält umfassende technische Details zu dieser Angriffsmethode. Im Google Security-Blogpost finden Sie ausführliche Informationen zu den Gegenmaßnahmen von Google einschließlich aller produktspezifischen Angaben.

Auswirkungen auf Compute Engine

Die Infrastruktur, auf der Compute Engine läuft und die die VM-Instanzen von Kunden voneinander isoliert, ist vor bekannten Angriffen geschützt. Unsere Gegenmaßnahmen verhindern den unbefugten Zugriff auf unsere Hostsysteme durch Anwendungen, die innerhalb von VM-Instanzen ausgeführt werden. Außerdem verhindern sie den nicht autorisierten Zugriff von VM-Instanzen auf andere VM-Instanzen, die auf demselben Hostsystem ausgeführt werden.

Um den nicht autorisierten Zugriff innerhalb Ihrer VM-Instanzen zu verhindern, müssen Sie die Gastbetriebssysteme dieser Instanzen über eine der folgenden Optionen aktualisieren:

  • Verwenden Sie gepatchte öffentliche Images, um Ihre vorhandenen VM-Instanzen neu zu erstellen. Unten finden Sie eine Liste der gepatchten öffentlichen Images.
  • Installieren Sie in Ihren vorhandenen Instanzen Patches, die vom Betriebssystemanbieter für Ihre Distribution zur Verfügung gestellt werden, und starten Sie die gepatchten Instanzen neu. Unten finden Sie Links zu den Patchinformationen der einzelnen Betriebssystemanbieter.

Gepatchte Images und Anbieterressourcen

Hinweis: Gepatchte Images enthalten möglicherweise nicht für alle CVEs, die in diesem Sicherheitsbulletin aufgeführt sind, Fehlerkorrekturen. Darüber hinaus können verschiedene Images unterschiedliche Methoden zum Verhindern dieser Angriffsarten enthalten. Erkundigen Sie sich bei Ihrem Betriebssystemanbieter, welche CVEs in den jeweiligen Patches behoben und welche Präventionsmethoden verwendet werden.

  • Projekt cos-cloud: Enthält Patches, die Angriffe der Variante 2 (CVE-2017-5715) und der Variante 3 (CVE-2017-5754) verhindern. Google hat Retpoline in diesen Images verwendet, um Angriffe vom Typ 2 zu minimieren.
    • cos-stable-63-10032-71-0 oder Image-Familie cos-stable
  • Projekt centos-cloud: CentOS-Patchinformationen
    • centos-7-v20180104 oder Image-Familie centos-7
    • centos-6-v20180104 oder Image-Familie centos-6
  • Projekt coreos-cloud: CoreOS-Patchinformationen
    • coreos-stable-1576-5-0-v20180105 oder Image-Familie coreos-stable
    • coreos-beta-1632-1-0-v20180105 oder Image-Familie coreos-beta
    • coreos-alpha-1649-0-0-v20180105 oder Image-Familie coreos-alpha
  • Projekt debian-cloud: Debian-Patchinformationen
    • debian-9-stretch-v20180105 oder Image-Familie debian-9
    • debian-8-jessie-v20180109 oder Image-Familie debian-8
  • Projekt rhel-cloud: RHEL-Patchinformationen
    • rhel-7-v20180104 oder Image-Familie rhel-7
    • rhel-6-v20180104 oder Image-Familie rhel-6
  • Projekt suse-cloud: SUSE-Patchinformationen
    • sles-12-sp3-v20180104 oder Image-Familie sles-12
    • sles-11-sp4-v20180104 oder Image-Familie sles-11
  • Projekt suse-sap-cloud: SUSE-Patchinformationen
    • sles-12-sp3-sap-v20180104 oder Image-Familie sles-12-sp3-sap
    • sles-12-sp2-sap-v20180104 oder Image-Familie sles-12-sp2-sap
  • Projekt ubuntu-os-cloud: Ubuntu-Patchinformationen
    • ubuntu-1710-artful-v20180109 oder Image-Familie ubuntu-1710
    • ubuntu-1604-xenial-v20180109 oder Image-Familie ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180110 oder Image-Familie ubuntu-1404-lts
  • Projekte windows-cloud und windows-sql-cloud:
    • Alle öffentlichen Images von Windows Server und SQL Server mit der Versionsnummer -v20180109 und höher enthalten Patches. Sie müssen jedoch die von Microsoft im Windows Server-Leitfaden gegebenen Empfehlungen befolgen, um diese Gegenmaßnahmen sowohl für vorhandene als auch für neu erstellte Instanzen zu aktivieren und zu überprüfen.

Verwenden Sie diese Images, um Ihre VM-Instanzen neu zu erstellen. Frühere Versionen dieser öffentlichen Images enthalten diese Patches nicht und können die Wirkung potenzieller Angriffe nicht abschwächen.

Patches von Hardwareanbietern

NVIDIA bietet gepatchte Treiber zur Minimierung von möglichen Angriffen auf Systeme mit installierter NVIDIA®-Treibersoftware. Welche Treiberversionen gepatcht wurden, entnehmen Sie dem Sicherheitsbulletin zu Grafiktreiber-Sicherheitsupdates für NVIDIA-GPUs von NVIDIA.

Überarbeitungsverlauf:

  • 21.05.2018, 14:00 Uhr (UTC -8): Informationen zu zwei neuen Varianten hinzugefügt, die am 21. Mai 2018 offengelegt wurden.
  • 11.01.2018, 15:00 Uhr (UTC -8): Informationen zu gepatchten öffentlichen Windows Server- und SQL Server-Images hinzugefügt.
  • 10.01.2018, 10:15 Uhr (UTC -8): Mehrere Ubuntu-Images zur Liste der gepatchten öffentlichen Images hinzugefügt.
  • 10.01.2018, 09:50 Uhr (UTC -8): Anleitung für Patches von Hardwareanbietern hinzugefügt.
  • 03.01.2018 bis 09.01.2018: Liste der gepatchten öffentlichen Images mehrfach überarbeitet.
Hoch

Veröffentlichungsdatum: 02.10.2017

Beschreibung Schweregrad Hinweise

Dnsmasq bietet Funktionen für DNS-, DHCP- und Router-Anzeigen sowie Netzwerkstarts. Diese Software ist üblicherweise auf Systemen mit Desktop-Linux-Distributionen (z. B. Ubuntu), Heimroutern und IoT-Geräten installiert. Dnsmasq wird sowohl im offenen Internet als auch intern für private Netzwerke eingesetzt.

Google hat bei regelmäßigen internen Sicherheitsanalysen sieben verschiedene Probleme entdeckt. Wir haben den Schweregrad dieser Probleme ermittelt und anschließend untersucht, wie sie sich auswirken und wie sie ausgenutzt werden können. Für jede einzelne Schwachstelle haben wir dann einen internen Proof of Concept erarbeitet. Zusätzlich haben wir gemeinsam mit Simon Kelly, der Dnsmasq betreut, entsprechende Patches entwickelt, um das Problem zu entschärfen.

Während der Überprüfung fand unser Team drei Möglichkeiten zur Remotecodeausführung, ein Datenleck und drei Denial-of-Service-Schwachstellen. Diese betreffen die neueste Version vom 5. September 2017, die auf dem Git-Server des Projekts liegt.

Die Patches wurden in das Git-Repository des Projekts eingepflegt.

Auswirkungen auf Compute Engine

Standardmäßig ist Dnsmasq nur in Images installiert, die NetworkManager verwenden, und inaktiv. In den folgenden öffentlichen Compute Engine-Images ist Dnsmasq installiert:

  • Ubuntu 16.04, 16.10, 17.04
  • CentOS 7
  • RHEL 7

Bei anderen Images ist Dnsmasq jedoch möglicherweise als Abhängigkeit für andere Pakete installiert. Wir empfehlen Ihnen, Ihre Debian-, Ubuntu-, CentOS-, RHEL-, SLES- und OpenSuse-Instanzen auf die neuesten Betriebssystem-Images zu aktualisieren. CoreOS und Container-Optimized OS sind nicht betroffen. Windows-Images sind ebenfalls nicht betroffen.

Instanzen, auf denen Debian oder Ubuntu ausgeführt wird, können durch Ausführung der folgenden Befehle auf der Instanz aktualisiert werden:

sudo apt-get -y update
sudo apt-get -y dist-upgrade

Für Red Hat Enterprise Linux- und CentOS-Instanzen führen Sie folgenden Befehl aus:

sudo yum -y upgrade

Für SLES- und OpenSUSE-Images führen Sie folgenden Befehl aus:

sudo zypper up

Alternativ zur Ausführung der manuellen Aktualisierungsbefehle können Sie auch VM-Instanzen mithilfe der Image-Familien des jeweiligen Betriebssystems neu erstellen.

Hoch

Veröffentlichungsdatum: 26.10.2016

Beschreibung Schweregrad Hinweise

CVE-2016-5195 ist eine Race Condition in der Art und Weise, wie das Speichersubsystem des Linux-Kernels den Bruch der COW-Situation (Copy-on-Write) bei schreibgeschützten privaten Zuordnungen bei Schreibzugriffen behandelt hat.

Ein nicht privilegierter lokaler Nutzer kann diese Sicherheitslücke ausnutzen, um Schreibzugriff auf ansonsten schreibgeschützte Speicherzuordnungen zu erhalten und so seine Berechtigungen auf dem System zu erhöhen.

Weitere Informationen finden Sie in der FAQ zu Dirty COW.

Auswirkungen auf Compute Engine

Alle Linux-Distributionen und ‑Versionen auf Compute Engine sind betroffen. Von den meisten Instanzen wird automatisch ein neuerer Kernel heruntergeladen und installiert. Zum Patchen laufender Systeme ist jedoch ein Neustart erforderlich.

In den neuen oder neu erstellten Instanzen, die auf den folgenden Compute Engine-Images basieren, sind bereits gepatchte Kernels installiert:

  • centos-6-v20161026
  • centos-7-v20161025
  • coreos-alpha-1192-2-0-v20161021
  • coreos-beta-1185-2-0-v20161021
  • coreos-stable-1122-3-0-v20161021
  • debian-8-jessie-v20161020
  • rhel-6-v20161026
  • rhel-7-v20161024
  • sles-11-sp4-v20161021
  • sles-12-sp1-v20161021
  • ubuntu-1204-precise-v20161020
  • ubuntu-1404-trusty-v20161020
  • ubuntu-1604-xenial-v20161020
  • ubuntu-1610-yakkety-v20161020
Hoch CVE-2016-5195

Veröffentlichungsdatum: 16.02.2016

Zuletzt aktualisiert: 22.02.2016

Beschreibung Schweregrad Hinweise

CVE-2015-7547 ist eine Sicherheitsanfälligkeit, bei der der glibc-DNS-Clientseitige Resolver Software anfällig für einen stapelbasierten Pufferüberlauf macht, wenn die getaddrinfo()-Bibliotheksfunktion verwendet wird. Ein Angreifer kann Software kapern, indem er diese Funktion verwendet, um die Sicherheitslücke mit von ihm kontrollierten Domainnamen oder DNS-Servern bzw. über eine Man-in-the-Middle-Attacke auszunutzen.

Weitere Informationen finden Sie im Google-Sicherheitsblogpost und in der Datenbank Common Vulnerabilities and Exposures (CVE).

Auswirkungen auf Compute Engine

Aktualisierung (22.02.2016):

Sie können Ihre Instanzen nun mit den folgenden CoreOS-, SLES- und OpenSUSE-Images erstellen:

  • coreos-alpha-962-0-0-v20160218
  • coreos-beta-899-7-0-v20160218
  • coreos-stable-835-13-0-v20160218
  • opensuse-13-2-v20160222
  • opensuse-leap-42-1-v20160222
  • sles-11-sp4-v20160222
  • sles-12-sp1-v20160222

Aktualisierung (17.02.2016):

Sie können jetzt durch Ausführung der folgenden Befehle eine Aktualisierung auf Ubuntu 12.04 LTS-, Ubuntu 14.04 LTS- und Ubuntu 15.10-Instanzen vornehmen:

  1. user@my-instance:~$ sudo apt-get -y update
  2. user@my-instance:~$ sudo apt-get -y dist-upgrade
  3. user@my-instance:~$ sudo reboot

Als Alternative zur Ausführung der manuellen Aktualisierungsbefehle können Sie jetzt mit folgenden neuen Images die Instanzen neu erstellen:

  • backports-debian-7-wheezy-v20160216
  • centos-6-v20160216
  • centos-7-v20160216
  • debian-7-wheezy-v20160216
  • debian-8-jessie-v20160216
  • rhel-6-v20160216
  • rhel-7-v20160216
  • ubuntu-1204-precise-v20160217a
  • ubuntu-1404-trusty-v20160217a
  • ubuntu-1510-wily-v20160217

Uns sind keine Methoden bekannt, mit denen diese Schwachstelle über den DNS-Resolver von Compute Engine in der Standardkonfiguration von glibc ausgenutzt werden kann. Wir empfehlen, Ihre VM-Instanzen so schnell wie möglich zu patchen, da wie bei jeder neuen Sicherheitslücke im Laufe der Zeit neue Exploits entdeckt werden können. Falls aktiviert, deaktivieren Sie edns0 (standardmäßig deaktiviert), bis die Instanzen gepatcht sind.

Originalmitteilung:

Ihre Linux-Distribution könnte anfällig sein. Compute Engine-Kunden, auf deren Instanzen ein Linux-Betriebssystem ausgeführt wird, müssen zum Schließen dieser Sicherheitslücke die Betriebssystem-Images ihrer Instanzen aktualisieren.

Instanzen, auf denen Debian ausgeführt wird, können durch Ausführung der folgenden Befehle auf der Instanz aktualisiert werden:

  1. user@my-instance:~$ sudo apt-get -y update
  2. user@my-instance:~$ sudo apt-get -y dist-upgrade
  3. user@my-instance:~$ sudo reboot

Wir empfehlen außerdem die Installation von UnattendedUpgrades für Debian-Instanzen.

Für Red Hat Enterprise Linux-Instanzen:

  • user@my-instance:~$ sudo yum -y upgrade
  • user@my-instance:~$ sudo reboot

Sobald andere Betriebssystem-Maintainer Patches für diese Schwachstelle veröffentlichen und aktualisierte Betriebssystem-Images von Compute Engine bereitgestellt werden, bringen wir dieses Bulletin auf den neuesten Stand.

Hoch CVE-2015-7547

Veröffentlichungsdatum: 19.03.2015

Beschreibung Schweregrad Hinweise

CVE-2015-1427 ist eine Sicherheitslücke, die es Remote-Angreifern über die Groovy Skript-Engine in Elasticsearch vor Version 1.3.8 und in allen 1.4.x-Versionen vor 1.4.3 ermöglicht, den Sandbox-Schutzmechanismus zu umgehen und beliebige Shell-Befehle auszuführen.

Ausführliche Informationen finden Sie in der National Vulnerability Database (NVD) und in der Datenbank Common Vulnerabilities and Exposures (CVE).

Auswirkungen auf Compute Engine

Wenn Sie Elasticsearch auf Ihren Compute Engine-Instanzen ausführen, sollten Sie die Elasticsearch-Version auf 1.4.3 oder höher aktualisieren. Wenn Sie bereits ein Upgrade Ihrer Elasticsearch-Software durchgeführt haben, sind Sie vor dieser Schwachstelle geschützt.

Wenn Sie kein Upgrade auf Elasticsearch 1.4.3 oder höher durchgeführt haben, können Sie ein Rolling Upgrade durchführen.

Wenn Sie Elasticsearch mit Click-to-Deploy in der Google Cloud consolebereitgestellt haben, können Sie die Bereitstellung löschen, um Instanzen zu entfernen, auf denen Elasticsearch ausgeführt wird.

Das Google Cloud -Team arbeitet an einer Lösung, um eine aktualisierte Version von Elasticsearch bereitzustellen. Diese Lösung ist jedoch noch nicht für die Click-to-Deploy-Funktion in der Google Cloud consoleverfügbar.

Hoch CVE-2015-1427

Veröffentlichungsdatum: 29.01.2015

Beschreibung Schweregrad Hinweise

CVE-2015-0235 (Ghost) ist eine Sicherheitslücke in der glibc-Bibliothek.

Kunden von App Engine, Cloud Storage, BigQuery und Cloud SQL müssen nichts weiter unternehmen. Die Google-Server wurden aktualisiert und sind vor dieser Sicherheitslücke geschützt.

Kunden von Compute Engine müssen unter Umständen ihre Betriebssystem-Images aktualisieren.

Auswirkungen auf Compute Engine

Ihre Linux-Distribution könnte anfällig sein. Compute Engine-Kunden, die Debian 7, Debian 7 Backports, Ubuntu 12.04 LTS, Red Hat Enterprise Linux, CentOS oder SUSE Linux Enterprise Server 11 SP3 ausführen, müssen zum Schließen dieser Sicherheitslücke das Betriebssystem-Image ihrer Instanzen aktualisieren.

Diese Schwachstelle betrifft weder Ubuntu 14.04 LTS noch Ubuntu 14.10 oder SUSE Linux Enterprise Server 12.

Wir empfehlen ein Upgrade Ihrer Linux-Distributionen. Instanzen, auf denen Debian 7, Debian 7 Backports oder Ubuntu 12.04 LTS ausgeführt wird, können durch Ausführung der folgenden Befehle auf der Instanz aktualisiert werden:

  1. user@my-instance:~$ sudo apt-get update
  2. user@my-instance:~$ sudo apt-get -y upgrade
  3. user@my-instance:~$ sudo reboot

Für Red Hat Enterprise Linux- oder CentOS-Instanzen:

  1. user@my-instance:~$ sudo yum -y upgrade
  2. user@my-instance:~$ sudo reboot

Für SUSE Linux Enterprise Server 11 SP3-Instanzen:

  1. user@my-instance:~$ sudo zypper --non-interactive up
  2. user@my-instance:~$ sudo reboot

Als Alternative zur Ausführung der manuellen Aktualisierungsbefehle können Sie jetzt mit folgenden neuen Images Ihre Instanzen neu erstellen:

  • debian-7-wheezy-v20150127
  • backports-debian-7-wheezy-v20150127
  • centos-6-v20150127
  • centos-7-v20150127
  • rhel-6-v20150127
  • rhel-7-v20150127
  • sles-11-sp3-v20150127
  • ubuntu-1204-precise-v20150127

Auswirkungen auf von Google verwaltete VMs

Nutzer von verwalteten VMs, die gcloud preview app deploy verwenden, müssen ihre Basis-Docker-Container mit gcloud preview app setup-managed-vms aktualisieren und jede ihrer ausgeführten Apps mit gcloud preview app deploy neu bereitstellen. Nutzer, die appcfg verwenden, müssen nichts unternehmen und werden automatisch aktualisiert.

Hoch CVE-2015-0235

Veröffentlichungsdatum: 15.10.2014

Zuletzt aktualisiert: 17.10.2014

Beschreibung Schweregrad Hinweise

CVE-2014-3566 (genannt POODLE) ist eine Schwachstelle im Design der SSL-Version 3.0. Durch diese Sicherheitslücke kann der Klartext gesicherter Verbindungen von einem Netzwerkangreifer berechnet werden. Weitere Informationen zu dieser Sicherheitslücke finden Sie in unserem Blogpost.

Kunden von App Engine, Cloud Storage, BigQuery und Cloud SQL müssen nichts weiter unternehmen. Die Google-Server wurden aktualisiert und sind vor dieser Sicherheitslücke geschützt. Kunden von Compute Engine müssen ihre Betriebssystem-Images aktualisieren.

Auswirkungen auf Compute Engine

Aktualisiert (17.10.2014):

Bei Verwendung von SSLv3 können Sie von dieser Schwachstelle betroffen sein. Compute Engine-Kunden müssen zum Schließen dieser Sicherheitslücke das Betriebssystem-Image ihrer Instanzen aktualisieren.

Wir empfehlen ein Upgrade Ihrer Linux-Distributionen. Instanzen, auf denen Debian ausgeführt wird, können durch Ausführung der folgenden Befehle auf der Instanz aktualisiert werden:

user@my-instance:~$ sudo apt-get update
user@my-instance:~$ sudo apt-get -y upgrade
user@my-instance:~$ sudo reboot

Für CentOS-Instanzen:

user@my-instance:~$ sudo yum -y upgrade
user@my-instance:~$ sudo reboot

Als Alternative zur Ausführung der obigen manuellen Aktualisierungsbefehle können Sie jetzt mit folgenden neuen Images Ihre Instanzen neu erstellen:

  • centos-6-v20141016
  • centos-7-v20141016
  • debian-7-wheezy-v20141017
  • backports-debian-7-wheezy-v20141017

Sobald uns die entsprechenden Images vorliegen, werden wir das Bulletin in Bezug auf RHEL- und SLES-Images aktualisieren. In der Zwischenzeit können RHEL-Nutzer weitere Informationen direkt von Red Hat beziehen.

Originalmitteilung:

Compute Engine-Kunden müssen zum Schließen dieser Sicherheitslücke das Betriebssystem-Image ihrer Instanzen aktualisieren. Sobald neue Betriebssystem-Images verfügbar sind, werden wir dieses Sicherheitsbulletin um weitere Anweisungen aktualisieren.

Mittel CVE-2014-3566

Veröffentlichungsdatum: 24.09.2014

Zuletzt aktualisiert: 29.09.2014

Beschreibung Schweregrad Hinweise

Ein Fehler in Bash (CVE-2014-6271) erlaubt die Codeausführung per Fernzugriff durch die Auswertung beliebiger vom Angreifer kontrollierter Umgebungsvariablen. Die wahrscheinlichste Methode für Exploits sind schädliche HTTP-Anfragen an CGI-Skripts, die auf einem Webserver verfügbar sind. Weitere Informationen entnehmen Sie der Fehlerbeschreibung.

Die Bash-Fehler wurden für alle Google Cloud -Produkte so weit wie möglich behoben. Davon ausgenommen sind Gastbetriebssystem-Images für Compute Engine, die vor dem 26.09.2014 erstellt wurden. Durch Ausführen der nachfolgend beschriebenen Schritte können Sie die Auswirkungen der Programmfehler auf Ihre Compute Engine-Images einschränken.

Auswirkungen auf Compute Engine

Dieser Fehler kann sich auf praktisch alle Websites auswirken, die CGI-Skripts verwenden. Außerdem sind wahrscheinlich Websites betroffen, die auf PHP, Perl, Python, SSI, Java, C++ und ähnlichen Servlets basieren, die Shell-Befehle über Aufrufe wie popen, system, shell_exec oder ähnliche APIs aufrufen. Dies kann sich auch auf Systeme auswirken, die versuchen, eingeschränkten Nutzern einen kontrollierten Anmeldezugriff über Mechanismen wie die SSH-Befehlsbeschränkung oder die eingeschränkte Bash-Shell zu ermöglichen.

Aktualisierung (29.09.2014):

Als Alternative zum Ausführen der manuellen Updatebefehle unten können Nutzer ihre Instanzen jetzt mit Images neu erstellen, die zusätzliche Sicherheitslücken im Zusammenhang mit dem Bash-Sicherheitsfehler beheben, darunter CVE-2014-7169, CVE-2014-6277, CVE-2014-6278, CVE-2014-7186 und CVE-2014-7187. Verwenden Sie zur Neu-Erstellung Ihrer Instanzen die folgenden neuen Images:

  • centos-6-v20140926
  • centos-7-v20140926
  • debian-7-wheezy-v20140926
  • backports-debian-7-wheezy-v20140926
  • rhel-6-v20140926

Update (25.09.2014):

Nutzer haben nun die Möglichkeit, ihre Instanzen neu zu erstellen, anstatt eine manuelle Aktualisierung durchzuführen. Verwenden Sie die folgenden neuen Images mit Korrekturen für diese Sicherheitslücke, um Ihre Instanzen neu zu erstellen:

  • backports-debian-7-wheezy-v20140924
  • debian-7-wheezy-v20140924
  • rhel-6-v20140924
  • centos-6-v20140924
  • centos-7-v20140924

Bei RHEL- und SUSE-Images können Sie auch manuelle Aktualisierungen vornehmen, indem Sie die folgenden Befehle auf den Instanzen ausführen:

# RHEL instances
user@my-instance:~$ sudo yum -y upgrade

# SUSE instances
user@my-instance:~$ sudo zypper --non-interactive up

Originalmitteilung:

Wir empfehlen ein Upgrade Ihrer Linux-Distributionen. Instanzen, auf denen Debian ausgeführt wird, können durch Ausführung der folgenden Befehle auf der Instanz aktualisiert werden:

user@my-instance:~$ sudo apt-get update
user@my-instance:~$ sudo apt-get -y upgrade

Für CentOS-Instanzen:

user@my-instance:~$ sudo yum -y upgrade

Ausführliche Informationen finden Sie in der Ankündigung der entsprechenden Linux-Distribution:

Hoch CVE-2014-7169, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278 CVE-2014-7186, CVE-2014-7187

Veröffentlichungsdatum: 25.07.2014

Beschreibung Schweregrad Hinweise

Elasticsearch Logstash ist anfällig für Befehlsinjektionen in das Betriebssystem, die unter Umständen eine nicht autorisierte Änderung und Weitergabe von Daten ermöglichen. Ein Angreifer kann gefälschte Ereignisse an eine beliebige Datenquelle von Logstash senden und somit Befehle mit den Rechten des Logstash-Prozesses ausführen.

Auswirkungen auf Compute Engine

Diese Schwachstelle betrifft alle Compute Engine-Instanzen, auf denen Versionen von Elasticsearch Logstash vor 1.4.2 mit aktivierten zabbix- oder nagios_nsca-Ausgaben ausgeführt werden. Zum Schutz vor Angriffen haben Sie folgende Optionen:

  • Upgrade auf Logstash 1.4.2 vornehmen
  • Patch für die Versionen 1.3.x anwenden
  • Deaktivieren Sie die Ausgaben zabbix und nagios_nsca.

Weitere Informationen finden Sie im Logstash-Blog.

Elasticsearch empfiehlt auch die Verwendung einer Firewall, um den Remotezugriff durch nicht vertrauenswürdige IP-Adressen zu vermeiden.

Hoch CVE-2014-4326

Veröffentlichungsdatum: 18.06.2014

Beschreibung Schweregrad Hinweise

Wir möchten uns einen Moment Zeit nehmen, um auf mögliche Bedenken einzugehen, die Kunden hinsichtlich der Sicherheit von Docker-Containern haben, wenn sie auf Google Cloudausgeführt werden. Dazu gehören Kunden, die unsere App Engine-Erweiterungen verwenden, von denen Docker-Container, für Container optimierte VMs oder der Open-Source-Scheduler Kubernetes unterstützt werden.

Docker hat vorbildlich auf das Problem reagiert. Die entsprechende Blogantwort finden Sie hier. Wie in der Antwort betont, gilt das entdeckte Problem nur für Docker 0.11, eine ältere Vorproduktionsversion.

Während alle Welt über Containersicherheit nachdenkt, möchten wir darauf aufmerksam machen, dass auf Linux-Anwendungscontainern beruhende Lösungen (insbesondere Docker-Container) in Google Cloudin vollständigen VMs (Compute Engine) ausgeführt werden. Wir unterstützen zwar die Bemühungen der Docker-Community, den Linux-Anwendungscontainer-Stack zu stärken, halten aber den Hinweis für wichtig, dass es sich um eine neue Technologie handelt, die eine große Oberfläche und damit auch Angriffsfläche bietet. Wir glauben, dass vollständige Hypervisoren (VMs) bislang eine kompaktere und leichter zu verteidigende Oberfläche bieten. VMs wurden von Anfang an mit dem Ziel entwickelt, schädliche Arbeitslasten zu isolieren und die Wahrscheinlichkeit des Auftretens sowie die Auswirkungen von möglichen Programmfehlern zu minimieren.

Unsere Kunden können sich auf eine vollständige Hypervisor-Grenze zwischen ihnen und potenziellem Schadcode Dritter verlassen. Wenn wir den Linux-Anwendungscontainer-Stack als robust genug für mandantenfähige Arbeitslasten befinden, werden wir die Community darüber in Kenntnis setzen. Derzeit ist der Linux-Anwendungscontainer kein Ersatz für die VM. Er ermöglicht jedoch eine wesentlich bessere Ausschöpfung ihrer Möglichkeiten.

Niedrig Docker-Blogpost

Veröffentlichungsdatum: 05.06.2014

Zuletzt aktualisiert: 09.06.2014

Beschreibung Schweregrad Hinweise

Ein Problem in OpenSSL besteht darin, dass die ChangeCipherSpec-Meldungen nicht richtig in die Zustandsmaschine für den Handshake eingebunden werden. Dadurch können sie vorzeitig in den Handshake injiziert werden. Angreifer können mit einem sorgfältig gefälschten Handshake die Verwendung von schwachem Verschlüsselungsmaterial auf OpenSSL SSL/TLS-Clients und -Servern erzwingen. Dies kann durch einen Man-in-the-Middle-Angriff ausgenutzt werden, indem der Angreifer den Datenverkehr vom angegriffenen Client und Server entschlüsselt und ändert.

Dieses Problem läuft unter der Kennung CVE-2014-0224. Das OpenSSL-Team hat das Problem behoben und die OpenSSL-Community aufgefordert, OpenSSL zu aktualisieren.

Auswirkungen auf Compute Engine

Diese Schwachstelle betrifft alle Compute Engine-Instanzen, die OpenSSL nutzen, einschließlich Debian, CentOS, Red Hat Enterprise Linux und SUSE Linux Enterprise Server. Sie können Ihre Instanzen aktualisieren, indem Sie diese mit den neuen Images erneut erstellen oder die Pakete auf den Instanzen manuell aktualisieren.

Aktualisierung (09.06.2014): Wenn Sie Ihre Instanzen, auf denen SUSE Linux Enterprise Server ausgeführt wird, mit neuen Images aktualisieren möchten, erstellen Sie die Instanzen mithilfe der folgenden oder höheren Image-Versionen neu:

  • sles-11-sp3-v20140609

Originalbeitrag:

Zum Aktualisieren von Debian- und CentOS-Instanzen mit neuen Images erstellen Sie die Instanzen mithilfe der folgenden oder höheren Image-Versionen neu:

  • debian-7-wheezy-v20140605
  • backports-debian-7-wheezy-v20140605
  • centos-6-v20140605
  • rhel-6-v20140605

Wenn Sie OpenSSL auf Ihren Instanzen manuell aktualisieren möchten, führen Sie die folgenden Befehle zur Aktualisierung der entsprechenden Pakete aus. Bei Instanzen, auf denen CentOS und RHEL ausgeführt wird, können Sie OpenSSL durch Ausführen dieser Befehle auf der Instanz aktualisieren:

user@my-instance:~$ sudo yum -y update
user@my-instance:~$ sudo reboot

Zum Aktualisieren von OpenSSL auf Instanzen, auf denen Debian läuft, können Sie die folgenden Befehle auf den Instanzen ausführen:

user@my-instance:~$ sudo apt-get update
user@my-instance:~$ sudo apt-get -y upgrade
user@my-instance:~$ sudo reboot

Bei Instanzen, auf denen SUSE Linux Enterprise Server ausgeführt wird, können Sie sich durch Ausführen der folgenden Befehle auf der Instanz überprüfen, ob OpenSSL auf dem neuesten Stand ist:

user@my-instance:~$ sudo zypper --non-interactive up
user@my-instance:~$ sudo reboot
Mittel CVE-2014-0224

Veröffentlichungsdatum: 08.04.2014

Beschreibung Schweregrad Hinweise

Die Implementierungen von (1) TLS und (2) DTLS in OpenSSL 1.0.1 vor 1.0.1g verarbeiten Heartbeat Extension-Pakete nicht richtig. Dadurch können Remote-Angreifer vertrauliche Informationen aus dem Prozessspeicher abrufen, indem sie speziell entwickelte Pakete verwenden, die einen Pufferüberlauf auslösen. Dies wird durch das Lesen privater Schlüssel im Zusammenhang mit d1_both.c und t1_lib.c demonstriert, auch bekannt als Heartbleed-Bug.

Auswirkungen auf Compute Engine

Diese Sicherheitslücke betrifft alle Compute Engine-Instanzen unter Debian, RHEL und CentOS, deren OpenSSL-Version nicht auf dem neuesten Stand ist. Sie können Ihre Instanzen aktualisieren, indem Sie sie mit neuen Images neu erstellen oder Pakete auf Ihren Instanzen manuell aktualisieren.

Zum Aktualisieren Ihrer Instanzen mit neuen Images erstellen Sie die Instanzen mithilfe der folgenden oder höheren Image-Versionen neu:

  • debian-7-wheezy-v20140408
  • backports-debian-7-wheezy-v20140408
  • centos-6-v20140408
  • rhel-6-v20140408

Wenn Sie OpenSSL auf Ihren Instanzen manuell aktualisieren möchten, führen Sie die folgenden Befehle zur Aktualisierung der entsprechenden Pakete aus. Bei Instanzen, auf denen CentOS und RHEL ausgeführt werden, können Sie sich durch Ausführen dieser Befehle auf der Instanz darüber vergewissern, dass OpenSSL auf dem neuesten Stand ist:

user@my-instance:~$ sudo yum update
user@my-instance:~$ sudo reboot

Zum Aktualisieren von OpenSSL auf Instanzen, auf denen Debian läuft, können Sie die folgenden Befehle auf den Instanzen ausführen:

user@my-instance:~$ sudo apt-get update
user@my-instance:~$ sudo apt-get upgrade
user@my-instance:~$ sudo reboot

Instanzen, auf denen SUSE Linux läuft, sind nicht betroffen.

Aktualisierung (14.04.2014): Angesichts neuer Erkenntnisse über das Auslesen von Schlüsseln mithilfe des Heartbleed-Programmfehlers wird Kunden von Compute Engine empfohlen, neue Schlüssel für eventuell betroffene SSL-Dienste zu erstellen.

Mittel CVE-2014-0160

Veröffentlichungsdatum: 07.06.2013

Beschreibung Schweregrad Hinweise

Hinweis: Diese Sicherheitslücke betrifft nur die Kernels, die ab API-Version v1 verworfen und entfernt wurden.

Eine Formatstring-Schwachstelle in der Funktion b43_request_firmware in drivers/net/wireless/b43/main.c im Broadcom B43-WLAN-Treiber im Linux-Kernel bis Version 3.9.4 ermöglicht es lokalen Nutzern, Rechte zu erlangen, indem sie Root-Zugriff nutzen und Formatstring-Spezifizierer in einen fwpostfix-modprobe-Parameter einfügen, was zu einer fehlerhaften Erstellung einer Fehlermeldung führt.

Auswirkungen auf Compute Engine

Diese Sicherheitslücke betrifft alle Compute Engine-Kernels vor gcg-3.3.8-201305291443. Daraufhin hat Compute Engine alle früheren Kernel eingestellt und empfiehlt Nutzern, ihre Instanzen und Images auf den Compute Engine-Kernel gce-v20130603 zu aktualisieren. gce-v20130603 enthält den Kernel gcg-3.3.8-201305291443, der den Patch für diese Sicherheitslücke enthält.

So finden Sie heraus, welche Kernelversion von einer Instanz verwendet wird:

  1. SSH-Verbindung zur Instanz herstellen
  2. Führen Sie uname -r aus
Mittel CVE-2013-2852

Veröffentlichungsdatum: 07.06.2013

Beschreibung Schweregrad Hinweise

Hinweis: Diese Sicherheitslücke betrifft nur diejenigen Kernels, die ab API-Version v1 verworfen und entfernt wurden.

Eine Formatstring-Schwachstelle in der Funktion „register_disk“ in block/genhd.c im Linux-Kernel bis einschließlich 3.9.4 ermöglicht es lokalen Nutzern, Rechte zu erlangen, indem sie Root-Zugriff nutzen und Formatstring-Spezifizierer in /sys/module/md_mod/parameters/new_array schreiben, um einen gefälschten Gerätenamen /dev/md zu erstellen.

Auswirkungen auf Compute Engine

Diese Sicherheitslücke betrifft alle Compute Engine-Kernels vor gcg-3.3.8-201305291443. Daraufhin hat Compute Engine alle früheren Kernel eingestellt und empfiehlt Nutzern, ihre Instanzen und Images auf den Compute Engine-Kernel gce-v20130603 zu aktualisieren. gce-v20130603 enthält den Kernel gcg-3.3.8-201305291443, der den Patch für diese Sicherheitslücke enthält.

So finden Sie heraus, welche Kernelversion von einer Instanz verwendet wird:

  1. SSH-Verbindung zur Instanz herstellen
  2. Führen Sie uname -r aus
Mittel CVE-2013-2851

Veröffentlichungsdatum: 14.05.2013

Beschreibung Schweregrad Hinweise

Hinweis: Diese Sicherheitslücke betrifft nur die Kernels, die ab API-Version v1 verworfen und entfernt wurden.

Die Funktion perf_swevent_init in kernel/events/core.c im Linux-Kernel vor 3.8.9 verwendet einen falschen integer-Datentyp, der es lokalen Nutzern ermöglicht, über einen gefälschten perf_event_open-Systemaufruf ihre Rechte zu erweitern.

Auswirkungen auf Compute Engine

Diese Sicherheitslücke betrifft alle Compute Engine-Kernels vor gcg-3.3.8-201305211623. Daraufhin hat Compute Engine alle früheren Kernel eingestellt und empfiehlt Nutzern, ihre Instanzen und Images auf den Compute Engine-Kernel gce-v20130521 zu aktualisieren. gce-v20130521 enthält den Kernel gcg-3.3.8-201305211623, der den Patch für diese Sicherheitslücke enthält.

So finden Sie heraus, welche Kernelversion von einer Instanz verwendet wird:

  1. SSH-Verbindung zur Instanz herstellen
  2. Führen Sie uname -r aus
Hoch CVE-2013-2094

Veröffentlichungsdatum: 18.02.2013

Beschreibung Schweregrad Hinweise

Hinweis: Diese Sicherheitslücke betrifft nur die Kernels, die ab API-Version v1 verworfen und entfernt wurden.

Eine Race-Bedingung in der ptrace-Funktion im Linux-Kernel vor 3.7.5 ermöglicht lokalen Nutzern, über einen PTRACE_SETREGS ptrace-Systemaufruf in einer gefälschten Anwendung ihre Rechte zu erweitern.

Auswirkungen auf Compute Engine

Diese Sicherheitslücke betrifft Compute Engine-Kernels 2.6.x-gcg-<date>. Daraufhin hat Compute Engine die 2.6.x-Kernel eingestellt und empfiehlt Nutzern, ihre Instanzen und Images auf den Compute Engine-Kernel gce-v20130225 zu aktualisieren. gce-v20130225 enthält den Kernel 3.3.8-gcg-201302081521, der den Patch für diese Sicherheitslücke enthält.

So finden Sie heraus, welche Kernelversion von einer Instanz verwendet wird:

  1. SSH-Verbindung zur Instanz herstellen
  2. Führen Sie uname -r aus
Mittel CVE-2013-0871