Sicherheitsbulletins

Auf dieser Seite werden alle Sicherheitsbulletins für die folgenden Produkte beschrieben:

  • Google Kubernetes Engine (GKE)
  • Anthos-Cluster auf VMware (GKE On-Prem)
  • Anthos-Cluster in AWS (GKE in AWS)
  • Anthos on Azure
  • Anthos-Cluster auf Bare Metal

Sicherheitslücken werden häufig geheim gehalten, bis die betroffenen Parteien die Möglichkeit hatten, sie zu beheben. In diesen Fällen wird in den Versionshinweisen von "Security Updates" (Sicherheitsupdates) gesprochen, bis die Geheimhaltungsverpflichtung aufgehoben wurde. Sobald dies geschehen ist, werden die Hinweise mit Informationen über die durch den Patch behobene Sicherheitslücke aktualisiert.

Wenn GKE ein Sicherheitsbulletin ausgibt, das sich direkt auf Ihre Clusterkonfiguration oder -version bezieht, senden wir Ihnen möglicherweise eine SecurityBulletinEvent-Clusterbenachrichtigung mit Informationen über die Sicherheitslücke und Maßnahmen, die Sie gegebenenfalls ergreifen können. Informationen zum Einrichten von Clusterbenachrichtigungen finden Sie unter Clusterbenachrichtigungen.

Weitere Informationen dazu, wie Google Sicherheitslücken und Patches für GKE und Anthos verwaltet, finden Sie unter Sicherheitspatches.

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

GCP-2022-014

Veröffentlicht: 26. 04. 2022
Referenz: CVE-2022-1055, CVE-2022-27666

GKE

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken entdeckt, CVE-2022-1055 und CVE-2022-27666. Beide können dazu führen, dass ein lokaler Angreifer in der Lage ist, einen Containerausfall, eine Ausweitung der Berechtigungen auf dem Host oder beides durchzuführen. Diese Sicherheitslücken betreffen alle Betriebssysteme von GKE-Knoten (Container-Optimized OS und Ubuntu).

Technische Details

Bei CVE-2022-1055 kann ein Angreifer use-after-free in tc_new_tfilter() ausnutzen. So kann ein lokaler Angreifer im Container seine Privilegien zum Root auf dem Knoten eskalieren.

Bei CVE-2022-27666 ermöglicht ein Pufferüberlauf in esp/esp6_output_head einem lokalen Angreifer im Container, die Berechtigungen zum Root auf dem Knoten zu eskalieren.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden kommenden GKE-Versionen:

  • 1.19.16-gke.11000 und höher
  • 1.20.15-gke.5200 und höher
  • 1.21.11-gke.1100 und höher
  • 1.22.8-gke.200 und höher
  • 1.23.5-gke.1500 und höher

Welche Sicherheitslücken werden mit diesem Patch behoben?

Hoch

Anthos-Cluster auf VMware

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken entdeckt, CVE-2022-1055 und CVE-2022-27666. Beide können dazu führen, dass ein lokaler Angreifer in der Lage ist, einen Containerausfall, eine Ausweitung der Berechtigungen auf dem Host oder beides durchzuführen. Diese Sicherheitslücken betreffen alle Betriebssysteme von GKE-Knoten (Container-Optimized OS und Ubuntu).

Technische Details

Bei CVE-2022-1055 kann ein Angreifer use-after-free in tc_new_tfilter() ausnutzen. So kann ein lokaler Angreifer im Container seine Privilegien zum Root auf dem Knoten eskalieren.

Bei CVE-2022-27666 ermöglicht ein Pufferüberlauf in esp/esp6_output_head einem lokalen Angreifer im Container, die Berechtigungen zum Root auf dem Knoten zu eskalieren.

Was soll ich tun?

Führen Sie ein Upgrade des Clusters auf eine Patchversion aus. Die folgenden Anthos-Cluster auf VMware-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

  • 1.9.6 (anstehend)
  • 1.10.3
  • 1.11.0 (anstehend)

Welche Sicherheitslücken werden mit diesem Patch behoben?

Hoch

Anthos-Cluster in AWS

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken entdeckt, CVE-2022-1055 und CVE-2022-27666. Beide können dazu führen, dass ein lokaler Angreifer in der Lage ist, einen Containerausfall, eine Ausweitung der Berechtigungen auf dem Host oder beides durchzuführen. Diese Sicherheitslücken betreffen alle Betriebssysteme von GKE-Knoten (Container-Optimized OS und Ubuntu).

Technische Details

Bei CVE-2022-1055 kann ein Angreifer use-after-free in tc_new_tfilter() ausnutzen. So kann ein lokaler Angreifer im Container seine Privilegien zum Root auf dem Knoten eskalieren.

Bei CVE-2022-27666 ermöglicht ein Pufferüberlauf in esp/esp6_output_head einem lokalen Angreifer im Container, die Berechtigungen zum Root auf dem Knoten zu eskalieren.

Was soll ich tun?

Führen Sie ein Upgrade des Clusters auf eine Patchversion aus. Patches werden in einer künftigen Version verfügbar sein. Dieses Bulletin wird aktualisiert, sobald sie verfügbar sind.

Welche Sicherheitslücken werden mit diesem Patch behoben?

Hoch

Anthos on Azure

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken entdeckt, CVE-2022-1055 und CVE-2022-27666. Beide können dazu führen, dass ein lokaler Angreifer in der Lage ist, einen Containerausfall, eine Ausweitung der Berechtigungen auf dem Host oder beides durchzuführen. Diese Sicherheitslücken betreffen alle Betriebssysteme von GKE-Knoten (Container-Optimized OS und Ubuntu).

Technische Details

Bei CVE-2022-1055 kann ein Angreifer use-after-free in tc_new_tfilter() ausnutzen. So kann ein lokaler Angreifer im Container seine Privilegien zum Root auf dem Knoten eskalieren.

Bei CVE-2022-27666 ermöglicht ein Pufferüberlauf in esp/esp6_output_head einem lokalen Angreifer im Container, die Berechtigungen zum Root auf dem Knoten zu eskalieren.

Was soll ich tun?

Führen Sie ein Upgrade des Clusters auf eine Patchversion aus. Patches werden in einer künftigen Version verfügbar sein. Dieses Bulletin wird aktualisiert, sobald sie verfügbar sind.

Welche Sicherheitslücken werden mit diesem Patch behoben?

Hoch

Anthos on Bare Metal

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken entdeckt, CVE-2022-1055 und CVE-2022-27666. Beide können dazu führen, dass ein lokaler Angreifer in der Lage ist, einen Containerausfall, eine Ausweitung der Berechtigungen auf dem Host oder beides durchzuführen. Diese Sicherheitslücken betreffen alle Betriebssysteme von GKE-Knoten (Container-Optimized OS und Ubuntu).

Technische Details

Bei CVE-2022-1055 kann ein Angreifer use-after-free in tc_new_tfilter() ausnutzen. So kann ein lokaler Angreifer im Container seine Privilegien zum Root auf dem Knoten eskalieren.

Bei CVE-2022-27666 ermöglicht ein Pufferüberlauf in esp/esp6_output_head einem lokalen Angreifer im Container, die Berechtigungen zum Root auf dem Knoten zu eskalieren.

Was soll ich tun?

Sie müssen nichts unternehmen. Anthos on Bare Metal ist von diesem CVE nicht betroffen, da Linux nicht in seinem Paket enthalten ist. Sie sollten dafür sorgen, dass die verwendeten Knoten-Images auf Versionen aktualisiert werden, die die Fehlerkorrektur für CVE-2022-1055 und CVE-2022-27666 enthalten.

Welche Sicherheitslücken werden mit diesem Patch behoben?

Hoch

GCP-2022-013

Veröffentlicht: 11.04.2022
Zuletzt aktualisiert: 20.04.2022
Referenz: CVE-2022-23648
22.04.2022 Update: Aktualisierte Patch-Versionen für Anthos auf Bare Metal und Anthos-Cluster auf VMware.

GKE

Beschreibung Schweregrad

Bei der Verarbeitung des Pfaddurchlaufs in der OCI-Volume-Spezifikation wurde eine Sicherheitslücke, CVE-2022-23648, entdeckt. Container, die über die CRI-Implementierung von containerd mit einer speziell konzipierten Image-Konfiguration gestartet wurden, können vollen Lesezugriff auf beliebige Dateien und Verzeichnisse auf dem Host erhalten.

Diese Sicherheitslücke kann jede richtlinienbasierte Durchsetzung bei der Containereinrichtung (einschließlich einer Kubernetes-Pod-Sicherheitsrichtlinie) umgehen. Diese Sicherheitslücke betrifft alle GKE-Knotenbetriebssysteme (Container-Optimized OS und Ubuntu), die standardmäßig containerd verwenden. Es sind alle GKE-, Autopilot- und GKE Sandbox-Knoten betroffen.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aus Sicherheitsgründen empfehlen wir, auch wenn Sie die automatische Knotenaktualisierung aktiviert haben, ein manuelles Upgrade Ihrer Knoten auf eine der folgenden GKE-Versionen durchzuführen:

  • 1.19.16-gke.9400
  • 1.20.15-gke.3600
  • 1.21.10-gke.1500
  • 1.22.7-gke.1500
  • 1.23.4-gke.1500

Mit der neuesten Funktion Release-Versionen können Sie einen Patch anwenden, ohne das Abo eines Kanals kündigen zu müssen. Auf diese Weise können Sie Ihre Knoten sichern, bis die neue Version als Standard für Ihre spezifische Release-Version verwendet wird.

Mittel

Anthos-Cluster auf VMware

Aktualisiert: 22.04.2022

Beschreibung Schweregrad

Bei der Verarbeitung des Pfaddurchlaufs in der OCI-Volume-Spezifikation wurde eine Sicherheitslücke, CVE-2022-23648, entdeckt. Container, die über die CRI-Implementierung von containerd mit einer speziell konzipierten Image-Konfiguration gestartet wurden, können vollen Lesezugriff auf beliebige Dateien und Verzeichnisse auf dem Host erhalten.

Diese Sicherheitslücke kann jede richtlinienbasierte Durchsetzung bei der Containereinrichtung (einschließlich einer Kubernetes-Pod-Sicherheitsrichtlinie) umgehen. Diese Sicherheitslücke betrifft alle Anthos-Cluster auf VMware mit aktiviertem Stackdriver, der containerd verwendet. Anthos-Cluster auf den VMware-Versionen 1.8, 1.9 und 1.10 sind betroffen

Was soll ich tun?

Aktualisierung vom 22. April 2022: Die folgenden Versionen von Anthos-Clustern auf VMware enthalten Code, der diese Sicherheitslücke behebt.

  • 1.9.5 oder höher
  • 1.10.3 oder höher
  • 1.11.0 oder höher

Die folgenden Versionen von Anthos-Cluster on VMware wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Wir empfehlen Ihnen, ein Upgrade Ihrer Knoten auf einen der folgenden Anthos-Cluster on VMware-Versionen durchzuführen:

  • 1.8.8 oder höher
  • 1.9.5 oder höher
  • 1.10.2 oder höher

Diese CVE-Sicherheitslücke kann durch die Festlegung von "IgnoreImageDefinedVolumes" auf "true" behoben werden.

Mittel

Anthos-Cluster in AWS

Beschreibung Schweregrad

Bei der Verarbeitung des Pfaddurchlaufs in der OCI-Volume-Spezifikation wurde eine Sicherheitslücke, CVE-2022-23648, entdeckt. Container, die über die CRI-Implementierung von containerd mit einer speziell konzipierten Image-Konfiguration gestartet wurden, können vollen Lesezugriff auf beliebige Dateien und Verzeichnisse auf dem Host erhalten.

Diese Sicherheitslücke kann jede richtlinienbasierte Durchsetzung bei der Containereinrichtung (einschließlich einer Kubernetes-Pod-Sicherheitsrichtlinie) umgehen. Alle Anthos-Cluster auf AWS-Versionen sind betroffen.

Was soll ich tun?

Die folgenden Versionen von Anthos-Cluster on AWS wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Wir empfehlen Ihnen, ein Upgrade Ihrer Knoten auf einen der folgenden Anthos-Cluster on AWS-Versionen durchzuführen.

Anthos-Cluster ion AWS (aktuelle Generation)
  • Version 1.22: 1.22.8-gke.200
  • Version 1.21: 1.21.11-gke.100
Anthos-Cluster in AWS (vorherige Generation)
  • Version 1.22: 1.22.8-gke.300
  • Version 1.21: 1.21.11-gke.100
  • Version 1.20: 1.20.15-gke.2200

Diese CVE-Sicherheitslücke kann durch die Festlegung von "IgnoreImageDefinedVolumes" auf "true" behoben werden.

Mittel

Anthos on Azure

Beschreibung Schweregrad

Bei der Verarbeitung des Pfaddurchlaufs in der OCI-Volume-Spezifikation wurde eine Sicherheitslücke, CVE-2022-23648, entdeckt. Container, die über die CRI-Implementierung von containerd mit einer speziell konzipierten Image-Konfiguration gestartet wurden, können vollen Lesezugriff auf beliebige Dateien und Verzeichnisse auf dem Host erhalten.

Diese Sicherheitslücke kann jede richtlinienbasierte Durchsetzung bei der Containereinrichtung (einschließlich einer Kubernetes-Pod-Sicherheitsrichtlinie) umgehen. Alle Anthos on Azure-Versionen sind betroffen.

Was soll ich tun?

Die folgenden Versionen von Anthos on Azure wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Wir empfehlen Ihnen, ein Upgrade Ihrer Knoten so auszuführen:

  • Version 1.22: 1.22.8-gke.200
  • Version 1.21: 1.21.11-gke.100

Diese CVE-Sicherheitslücke kann durch die Festlegung von "IgnoreImageDefinedVolumes" auf "true" behoben werden.

Mittel

Anthos on Bare Metal

Aktualisiert: 22.04.2022

Beschreibung Schweregrad

Bei der Verarbeitung des Pfaddurchlaufs in der OCI-Volume-Spezifikation wurde eine Sicherheitslücke, CVE-2022-23648, entdeckt. Container, die über die CRI-Implementierung von containerd mit einer speziell konzipierten Image-Konfiguration gestartet wurden, können vollen Lesezugriff auf beliebige Dateien und Verzeichnisse auf dem Host erhalten.

Diese Sicherheitslücke kann jede richtlinienbasierte Durchsetzung bei der Containereinrichtung (einschließlich einer Kubernetes-Pod-Sicherheitsrichtlinie) umgehen. Diese Sicherheitslücke betrifft alle Anthos on Bare Metal-Instanzen, die containerd verwenden. Die Versionen 1.8, 1.9 und 1.10 von Anthos on Bare Metal sind betroffen

Was soll ich tun?

Aktualisierung vom 22. April 2022: Die folgenden Versionen von Anthos on Bare Metal enthalten Code, der diese Sicherheitslücke behebt.

  • 1.8.9 oder höher
  • 1.9.6 oder höher
  • 1.10.3 oder höher
  • 1.11.0 oder höher

Die folgenden Versionen von Anthos on Bare Metal wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Wir empfehlen Ihnen, ein Upgrade Ihrer Knoten auf eine der folgenden Anthos on Bare Metal-Versionen durchzuführen:

  • 1.8.8 oder höher
  • 1.9.5 oder höher
  • 1.10.2 oder höher

Diese CVE-Sicherheitslücke kann durch die Festlegung von "IgnoreImageDefinedVolumes" auf "true" behoben werden.

Mittel

GCP-2022-012

Veröffentlicht: 2022-04-07
Referenz: CVE-2022-0847

GKE

Beschreibung Schweregrad

Im Linux-Kernel ab Version 5.8 wurde eine Sicherheitslücke (CVE-2022-0847) entdeckt, durch die möglicherweise Root-Rechte erlangt werden können. Diese Sicherheitslücke betrifft alle GKE-Knotenpoolversionen ab v1.22, die Container-Optimized OS-Images verwenden (Container-Optimized OS 93 und höher). GKE-Knotenpools, die das Ubuntu-Betriebssystem verwenden, sind nicht betroffen.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aus Sicherheitsgründen empfehlen wir, auch wenn Sie die automatische Knotenaktualisierung aktiviert haben, ein manuelles Upgrade Ihrer Knotenpools auf eine der folgenden GKE-Versionen durchzuführen:

  • 1.22.7-gke.1500 und höher
  • 1.23.4-gke.1600 und höher

Mit der neuesten Funktion Release-Versionen können Sie eine Patchversion anderer Release-Versionen anwenden, ohne sich von einer Version abmelden zu müssen. Auf diese Weise können Sie Ihre Knoten sichern, bis die neue Version zur Standardversion für Ihre Release-spezifische Version wird.

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-0847 bezieht sich auf das Flag PIPE_BUF_FLAG_CAN_MERGE, das in Version 5.8 des Linux-Kernels eingeführt wurde. Bei dieser Sicherheitslücke wurde das Mitglied "flags" der neuen Pipe-Pufferstruktur im Linux-Kernel nicht ordnungsgemäß initialisiert. Ein nicht privilegierter lokaler Angreifer kann diesen Fehler ausnutzen, um auf Seiten im Seiten-Cache zu schreiben, die durch schreibgeschützte Dateien gesichert sind, und seine Privilegien eskalieren.

Neue Versionen von Container-Optimized OS, die dieses Problem beheben, wurden in die aktualisierten Knotenpoolversionen von GKE integriert.

Hoch

Anthos-Cluster auf VMware

Beschreibung Schweregrad

Im Linux-Kernel ab Version 5.8 wurde eine Sicherheitslücke (CVE-2022-0847) entdeckt, durch die möglicherweise Root-Rechte erlangt werden können. Diese Sicherheitslücke betrifft Anthos-Cluster auf VMware v1.10 für Container-Optimized OS-Images. Derzeit befinden sich Anthos-Cluster auf VMware mit Ubuntu auf der Kernel-Version 5.4 und sind nicht anfällig für diesen Angriff.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos-Clustern on VMware wurden mit Code aktualisiert, um diese Sicherheitslücke zu beheben. Wir empfehlen Ihnen, ein Upgrade Ihrer Administrator- und Nutzercluster auf die folgenden Anthos-Cluster on VMware-Version auszuführen:

  • 1.10.3

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-0847 bezieht sich auf das Flag PIPE_BUF_FLAG_CAN_MERGE, das in Version 5.8 des Linux-Kernels eingeführt wurde. Bei dieser Sicherheitslücke wurde das Mitglied "flags" der neuen Pipe-Pufferstruktur im Linux-Kernel nicht ordnungsgemäß initialisiert. Ein nicht privilegierter lokaler Angreifer kann diesen Fehler ausnutzen, um auf Seiten im Seiten-Cache zu schreiben, die durch schreibgeschützte Dateien gesichert sind, und seine Privilegien eskalieren.

Neue Versionen von Container-Optimized OS, die dieses Problem beheben, wurden in die aktualisierten Versionen von Anthos-Clustern auf VMware integriert.

Hoch

Anthos-Cluster in AWS

Beschreibung Schweregrad

Im Linux-Kernel ab Version 5.8 wurde eine Sicherheitslücke (CVE-2022-0847) entdeckt, durch die möglicherweise Root-Rechte erlangt werden können.

Diese Sicherheitslücke betrifft verwaltete Cluster von Anthos-Clustern on AWS v1.21 und in Clustern, die auf Anthos-Clustern on AWS (vorherige Generation) v1.19, v1.20, v1.21 ausgeführt werden, die Ubuntu verwenden.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos-Cluster on AWS wurden mit Code aktualisiert, um diese Sicherheitslücke zu beheben.

Für verwaltete Anthos-Cluster on AWS empfehlen wir ein Upgrade Ihrer Nutzercluster und Knotenpools auf eine der folgenden Versionen:

  • 1.21.11-gke.100

Für k-lite-Anthos-Cluster on AWS empfehlen wir ein Upgrade Ihrer AWSManagementService-, AWSCluster- und AWSNodePool-Objekte auf die folgende Version:

  • 1.21.11-gke.100
  • 1.20.15-gke.2200

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-0847 bezieht sich auf das Flag PIPE_BUF_FLAG_CAN_MERGE, das in Version 5.8 des Linux-Kernels eingeführt wurde. Bei dieser Sicherheitslücke wurde das Mitglied "flags" der neuen Pipe-Pufferstruktur im Linux-Kernel nicht ordnungsgemäß initialisiert. Ein nicht privilegierter lokaler Angreifer kann diesen Fehler ausnutzen, um auf Seiten im Seiten-Cache zu schreiben, die durch schreibgeschützte Dateien gesichert sind, und seine Privilegien eskalieren.

Hoch

Anthos on Azure

Beschreibung Schweregrad

Im Linux-Kernel ab Version 5.8 wurde eine Sicherheitslücke (CVE-2022-0847) entdeckt, durch die möglicherweise Root-Rechte erlangt werden können. Diese Sicherheitslücke betrifft verwaltete Cluster von Anthos on Azure v1.21, die Ubuntu verwenden.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos on Azure wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Wir empfehlen Ihnen, ein Upgrade Ihrer Nutzercluster und Ihres Knotenpools auf die folgende Version durchzuführen:

  • 1.21.11-gke.100

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-0847 bezieht sich auf das Flag PIPE_BUF_FLAG_CAN_MERGE, das in Version 5.8 des Linux-Kernels eingeführt wurde. Bei dieser Sicherheitslücke wurde das Mitglied "flags" der neuen Pipe-Pufferstruktur im Linux-Kernel nicht ordnungsgemäß initialisiert. Ein nicht privilegierter lokaler Angreifer kann diesen Fehler ausnutzen, um auf Seiten im Seiten-Cache zu schreiben, die durch schreibgeschützte Dateien gesichert sind, und seine Privilegien eskalieren.

Hoch

Anthos on Bare Metal

Beschreibung Schweregrad

Im Linux-Kernel ab Version 5.8 wurde eine Sicherheitslücke (CVE-2022-0847) entdeckt, durch die möglicherweise Root-Rechte erlangt werden können.

Was soll ich tun?

Sie müssen nichts unternehmen. Anthos on Bare Metal ist von diesem CVE nicht betroffen, da Linux nicht in seinem Paket enthalten ist. Sie sollten dafür sorgen, dass die verwendeten Knoten-Images auf Versionen aktualisiert werden, die die Fehlerkorrektur für CVE-2022-0847 enthalten.

Hoch

GCP-2022-011

Veröffentlicht: 22.03.2022

GKE

Beschreibung Schweregrad

Es gibt eine fehlerhafte Konfiguration beim Gleichzeitigen Multi-Threading (SMT), auch als Hyper-Threading bezeichnet, auf GKE Sandbox-Images. Durch eine fehlerhafte Konfiguration werden Knoten möglicherweise für Nebenkanalangriffe wie Microarchitectural Data Sampling (MDS) ausgesetzt. Weitere Informationen finden Sie in der GKE Sandbox-Dokumentation. Wir raten davon ab, die folgenden betroffenen Versionen zu verwenden:

  • 1.22.4-gke.1501
  • 1.22.6-gke.300
  • 1.23.2-gke.300
  • 1.23.3-gke.600

Wenn Sie SMT für einen Knotenpool manuell aktiviert haben, wirkt sich dieses Problem nicht auf Ihre in der Sandbox ausgeführten Knoten aus.

Was soll ich tun?

Führen Sie ein Upgrade Ihrer Knoten auf eine der folgenden Versionen durch:

  • 1.22.6-gke.1500 und höher
  • 1.23.3-gke.1100 und höher

Welche Sicherheitslücke wird mit diesem Patch behoben?

Bei GKE-Sandbox-Knoten ist SMT standardmäßig deaktiviert, um Seitenkanalangriffe abzuschwächen.

Mittel

GCP-2022-009

Veröffentlicht: 01.03.2022
Zuletzt aktualisiert: 15.03.2022

GKE

Beschreibung Schweregrad

Aktualisierung vom 15.03.2022: Es wurden Leitfäden zur Härtung für Anthos-Cluster in AWS (GKE on AWS) und Anthos on Azure hinzugefügt. Abschnitt zur Persistenz mit Webhooks hinzugefügt.


Einige unerwartete Pfade für den Zugriff auf die Knoten-VM in GKE Autopilot-Clustern wurden möglicherweise verwendet, um Berechtigungen im Cluster zu eskalieren. Diese Probleme wurden behoben und es sind keine weiteren Maßnahmen erforderlich. Die Fehlerkorrekturen beheben Probleme, die über unser Vulnerability Reward Program gemeldet wurden.

Nutzer von GKE-Standard- und -Anthos-Clustern können optional eine ähnliche Richtlinie zur Härtung anwenden, wie unten beschrieben.

Technische Details

Hostzugriff mit Richtlinienausnahmen von Drittanbietern

Damit Google Cloud die vollständige Verwaltung von Knoten und ein SLA auf Pod-Ebene anbieten kann, beschränkt GKE Autopilot einige privilegierte Kubernetes-Primitive, um Arbeitslasten auf Low-Level-Zugriff auf die Knoten-VM zu beschränken. So legen Sie den Kontext fest: GKE Standard bietet vollständigen Zugriff auf das zugrunde liegende Computing, Autopilot bietet eingeschränkten Zugriff und Cloud Run bietet keinen Zugriff.

Autopilot lockert einige dieser Einschränkungen für eine vordefinierte Liste von Drittanbietertools, sodass Kunden diese Tools auf Autopilot ohne Änderung ausführen können. Mithilfe von Berechtigungen zum Erstellen von Pods mit Hostpfadbereitstellungen konnte der Forscher einen privilegierten Container in einem Pod ausführen, der wie eines dieser Tools von Drittanbietern aussieht, um Zugriff auf den Host zu erhalten.

Die Möglichkeit, Pods auf diese Weise zu planen, wird im GKE-Standard erwartet, aber nicht in GKE Autopilot, da die Hostzugriffseinschränkungen umgangen wurden, die zum Aktivieren des zuvor beschriebenen SLA verwendet wurden.

Dieses Problem wurde durch eine Verkürzung der Pod-Spezifikation des Drittanbieters für Zulassungslisten behoben.

Rechteausweitung von Root-auf-Knoten

Zusätzlich zum Hostzugriff wurden die Pods stackdriver-metadata-agent-cluster-level und metrics-server als stark privilegiert identifiziert. Nachdem der Zugriff auf Stammebene auf den Knoten erfolgt ist, können diese Dienste zur weiteren Kontrolle des Clusters verwendet werden.

Wir haben die stackdriver-metadata-agent sowohl für den GKE-Standard als auch für Autopilot verworfen und entfernt. Diese Komponente wird noch auf Anthos-Clustern in VMware und Anthos auf Bare-Metal verwendet.

Als Maßnahmen zur Systemhärtung, um diese Art von Angriff in Zukunft zu verhindern, werden wir in einer künftigen Version eine Autopilot-Einschränkung anwenden, die Aktualisierungen des Dienstkontos verschiedener Objekte im Namespace kube-system verhindert. Wir haben eine Gatekeeper-Richtlinie entwickelt, mit der Sie einen ähnlichen Schutz auf GKE-Standardcluster und Anthos-Cluster anwenden können, um eine privilegierte Änderung der privilegierten Arbeitslast zu verhindern. Diese Richtlinie wird automatisch auf Autopilot-Cluster angewendet. Eine Anleitung finden Sie in den folgenden Anleitungen zur Härtung:


Ergänzung am 15.03.2022: Persistenz mit mutierenden Webhooks

In dem Bericht wurden mutierende Webhooks verwendet, um sich nach der Kompromittierung einen privilegierten Zugang zum Cluster zu verschaffen. Dies sind Standardteile der Kubernetes API, die von Clusteradministratoren erstellt und für Administratoren sichtbar gemacht werden, wenn Autopilot Unterstützung für benutzerdefinierte Webhooks hinzufügt.


Privilegierte Dienstkonten im Standard-Namespace

Autopilot-Richtlinienerzwinger haben zuvor zwei Dienstkonten im Standard-Namespace zugelassen: csi-attacher und otelsvc, um den Dienstkonten spezielle Berechtigungen zu erteilen. Ein Angreifer mit hohen Berechtigungen, einschließlich Berechtigungen zum Erstellen von ClusterRoleBinding-Objekten und mit Zugriff zum Erstellen von Pods im Standard-Namespace, kann mit diesen Dienstkontonamen auf diese zusätzlichen Berechtigungen zugreifen. Diese Dienste wurden unter den Namespace kube-system verschoben, um den Schutz der vorhandenen Autopilot-Richtlinie zu erhalten. GKE-Standardcluster und Anthos-Cluster sind nicht betroffen.

Was soll ich tun?

Die Richtlinien aller GKE Autopilot-Cluster wurden aktualisiert, um den unbeabsichtigten Hostzugriff zu entfernen, und keine weiteren Maßnahmen sind erforderlich.

In den nächsten Wochen wird eine weitere Härtung der Richtlinien als sekundärer Schutz auf Autopilot angewendet. Sie müssen nichts unternehmen.

GKE-Standardcluster und Anthos-Cluster sind nicht betroffen, da Nutzer bereits Zugriff auf den Host haben. Als Systemstabilisierungsmaßnahme können GKE-Standardcluster und Anthos-Clusternutzer einen ähnlichen Schutz mit einer Gatekeeper-Richtlinie anwenden, die die Selbstmodifikation privilegierter Arbeitslasten verhindert. Eine Anleitung finden Sie in den folgenden Anleitungen zur Härtung:

Niedrig

GCP-2022-008

Veröffentlicht: 23. 02. 2022
Aktualisiert: 28. 04. 2022
Referenz: CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, CVE-2022-21656

GKE

Beschreibung Schweregrad
Das Envoy-Projekt hat kürzlich mehrere Sicherheitslücken festgestellt: CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657 und CVE-2022-21656, die sich auf GKE-Cluster mit Anthos Service Mesh, Istio-on-GKE oder benutzerdefinierte Istio-Deployments auswirken können.
Alle unten aufgeführten Probleme wurden im Envoy-Release 1.21.1 behoben.
Technischer Hintergrund
Weitere Details zu diesen Sicherheitslücken finden Sie hier.

Was soll ich tun?

GKE-Cluster, auf denen Anthos Service Mesh ausgeführt wird, sollten auf eine unterstützte Version aktualisiert werden, wobei die oben genannten Sicherheitslücken behoben werden.
  • Wenn Sie Anthos Service Mesh 1.12 verwenden, führen Sie ein Upgrade auf v1.12.4-asm.0 durch. .
  • Wenn Sie Anthos Service Mesh 1.11 verwenden, führen Sie ein Upgrade auf v1.11.7-asm.1 durch.
  • Wenn Sie Anthos Service Mesh 1.10 verwenden, führen Sie ein Upgrade auf v1.10.6-asm.1 durch.
Wenn Sie Anthos Service Mesh Version 1.9 oder niedriger verwenden, ist Ihre Version abgelaufen und wird nicht mehr unterstützt. Diese CVE-Korrekturen wurden nicht zurückportiert. Sie sollten ein Upgrade auf ASM 1.10 oder höher ausführen.

GKE-Cluster, auf denen Istio-on-GKE ausgeführt wird, sollten auf eine unterstützte Version aktualisiert werden, wobei die oben genannten Sicherheitslücken behoben werden
  • Wenn Sie Istio-on-GKE 1.6 verwenden, führen Sie ein Upgrade auf v1.6.14-gke.8 durch.
  • Wenn Sie Istio-on-GKE 1.4.11 verwenden, führen Sie ein Upgrade auf v1.4.11-gke.4 durch.
  • Wenn Sie Istio-on-GKE 1.4.10 verwenden, führen Sie ein Upgrade auf v1.4.10-gke.23 durch.
  • Wenn Sie GKE 1.22 oder höher verwenden, verwenden Sie bitte Istio GKE 1.4.10. Verwenden Sie andernfalls Istio-on-GKE 1.4.11.

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, und CVE-2022-21656
Hoch

Anthos-Cluster auf VMware

Aktualisiert: 28. 04. 2022

Beschreibung Schweregrad
Envoy hat kürzlich mehrere Fehlerkorrekturen für Sicherheitslücken veröffentlicht. Anthos-Cluster auf VMware sind betroffen, da Envoy mit Metrics-Server verwendet wird. Die von uns behobenen Envoy-CVEs sind unten aufgeführt. Wir aktualisieren dieses Bulletin, sobald sie verfügbar sind:
  • CVE-2021-43824 (CVSS-Punktzahl 6,5, mittel): Potenzieller Nullzeiger bei Verwendung der JWT-Filter-Safe_Regex-Übereinstimmung.
    Hinweis: Obwohl ASM/Istio-on-GKE keine Envoy-Filter unterstützt, können Sie betroffen sein, wenn Sie einen Regex-Filter für JWT verwenden.
  • CVE-2021-43825 (CVSS-Punktzahl 6,1, mittel): Use-after-Free, wenn Antwortfilter die Antwortdaten erhöhen und mehr Daten die nachgelagerten Pufferlimits überschreiten.
    Hinweis: ASM/Istio-on-GKE unterstützt zwar keine Envoy-Filter, Sie können jedoch betroffen sein, wenn Sie einen Filter zum Dekomprimieren verwenden.
  • CVE-2021-43826 (CVSS-Punktzahl 6,1, mittel): Use-after-Free, wenn TCP über HTTP getunnelt wird, wenn die Downstream-Verbindung während des Upstream-Verbindungsaufbaus unterbrochen wird.
    Hinweis: ASM/Istio-on-GKE unterstützt zwar keine Envoy-Filter, Sie können aber trotzdem betroffen sein, wenn Sie einen Tunneling-Filter verwenden.
  • CVE-2022-21654 (CVSS-Punktzahl 7,3, hoch): Die falsche Konfigurationsbehandlung ermöglicht die Wiederverwendung von mTLS-Sitzungen ohne erneute Validierung, nachdem sich die Validierungseinstellungen geändert haben.
    Hinweis: Alle ASM-/Istio-on-GKE-Dienste, die mTLS verwenden, sind von diesem CVE betroffen.
  • CVE-2022-21655 (CVSS-Punktzahl 7,5, hoch): Falsche Verarbeitung interner Weiterleitungen an Routen mit einer direkten Antwort.
    Hinweis: ASM/Istio-on-GKE unterstützt zwar keine Envoy-Filter, Sie können aber trotzdem betroffen sein, wenn Sie einen Filter für direkte Antworten verwenden.
  • CVE-2022-23606 (CVSS-Punktzahl 4,4, mittel): Stacküberlastung, wenn ein Cluster über den Cluster Discovery-Dienst gelöscht wird.
    Hinweis: ASM 1.11 und höher ist von dieser CVE-Sicherheitslücke betroffen. ASM 1.10 und alle Istio-on-GKE-Umgebungen sind von diesem CVE nicht betroffen.
  • CVE-2022-21657 (CVSS Score 3,1, niedrig): Envoy bis Version 1.20.1 enthält eine per Fernzugriff ausnutzbare Sicherheitslücke, da X.509 Extended Key Usage and Trust Purposes umgangen wird.
  • CVE-2022-21656 (CVSS-Punktzahl 3,1, niedrig): Envoy bis Version 1.20.1 enthält eine per Fernzugriff ausnutzbare Sicherheitslücke, da der Abgleich von X.509 subjectAltName (und nameConstraints) umgangen wird.

Istio hat kürzlich eine Fehlerkorrektur für eine Sicherheitslücke veröffentlicht. Anthos auf VMware ist betroffen, da Istio für eingehenden Traffic verwendet wird. Die von uns behobenen Istio CVEs sind unten aufgeführt. Wir aktualisieren dieses Bulletin, sobald sie verfügbar sind.

CVE-2022-23635 (CVSS-Punktzahl 7,5, hoch): Istiod stürzt ab, wenn Anfragen mit einem speziell erstellten Autorisierungsheader empfangen werden.


Die vollständigen Beschreibungen und Auswirkungen der oben genannten CVEs finden Sie in den Sicherheitsbulletins.

Erweiterung vom 28. 04. 2020: Was soll ich tun?

Mit den folgenden Versionen von Anthos-Clustern auf VMware werden diese Sicherheitslücken behoben:

  • 1.9.5
  • 1.10.3
  • 1.11.0

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, und CVE-2022-21656
Hoch

Anthos on Bare Metal

Beschreibung Schweregrad
Envoy hat kürzlich mehrere Fehlerkorrekturen für Sicherheitslücken veröffentlicht. Anthos auf Bare-Metal ist betroffen, da Envoy für Metrics-Server verwendet wird. Die von Envoy behobenen CVEs in Version 1.10.3, 1.9.6 und 1.8.9 sind unten aufgeführt:
  • CVE-2021-43824 (CVSS-Punktzahl 6,5, mittel): Potenzieller Nullzeiger bei Verwendung der JWT-Filter-Safe_Regex-Übereinstimmung.
    Hinweis: Obwohl ASM/Istio-on-GKE keine Envoy-Filter unterstützt, können Sie betroffen sein, wenn Sie einen Regex-Filter für JWT verwenden.
  • CVE-2021-43825 (CVSS-Punktzahl 6,1, mittel): Use-after-Free, wenn Antwortfilter die Antwortdaten erhöhen und mehr Daten die nachgelagerten Pufferlimits überschreiten.
    Hinweis: ASM/Istio-on-GKE unterstützt zwar keine Envoy-Filter, Sie können jedoch betroffen sein, wenn Sie einen Filter zum Dekomprimieren verwenden.
  • CVE-2021-43826 (CVSS-Punktzahl 6,1, mittel): Use-after-Free, wenn TCP über HTTP getunnelt wird, wenn die Downstream-Verbindung während des Upstream-Verbindungsaufbaus unterbrochen wird.
    Hinweis: ASM/Istio-on-GKE unterstützt zwar keine Envoy-Filter, Sie können aber trotzdem betroffen sein, wenn Sie einen Tunneling-Filter verwenden.
  • CVE-2022-21654 (CVSS-Punktzahl 7,3, hoch): Die falsche Konfigurationsbehandlung ermöglicht die Wiederverwendung von mTLS-Sitzungen ohne erneute Validierung, nachdem sich die Validierungseinstellungen geändert haben.
    Hinweis: Alle ASM-/Istio-on-GKE-Dienste, die mTLS verwenden, sind von diesem CVE betroffen.
  • CVE-2022-21655 (CVSS-Punktzahl 7,5, hoch): Falsche Verarbeitung interner Weiterleitungen an Routen mit einer direkten Antwort.
    Hinweis: ASM/Istio-on-GKE unterstützt zwar keine Envoy-Filter, Sie können aber trotzdem betroffen sein, wenn Sie einen Filter für direkte Antworten verwenden.
  • CVE-2022-23606 (CVSS-Punktzahl 4,4, mittel): Stacküberlastung, wenn ein Cluster über den Cluster Discovery-Dienst gelöscht wird.
    Hinweis: ASM 1.11 und höher ist von dieser CVE-Sicherheitslücke betroffen. ASM 1.10 und alle Istio-on-GKE-Umgebungen sind von diesem CVE nicht betroffen.
  • CVE-2022-21657 (CVSS Score 3,1, niedrig): Envoy bis Version 1.20.1 enthält eine per Fernzugriff ausnutzbare Sicherheitslücke, da X.509 Extended Key Usage and Trust Purposes umgangen wird.
  • CVE-2022-21656 (CVSS-Punktzahl 3,1, niedrig): Envoy bis Version 1.20.1 enthält eine per Fernzugriff ausnutzbare Sicherheitslücke, da der Abgleich von X.509 subjectAltName (und nameConstraints) umgangen wird.
Istio hat kürzlich eine Fehlerkorrektur für eine Sicherheitslücke veröffentlicht. Anthos auf Bare Metal ist betroffen, da Istio für eingehenden Traffic verwendet wird. Die in der Version 1.10.3, 1.9.6 und 1.8.9 behobenen Istio-CVEs sind unten aufgeführt:

  • CVE-2022-23635 (CVSS-Punktzahl 7,5, hoch): Istiod stürzt ab, wenn Anfragen mit einem speziell erstellten Autorisierungsheader empfangen werden.
    Hinweis: Alle ASM-/Istio-on-GKE-Konfigurationen sind von diesem CVE betroffen.

Die vollständigen Beschreibungen und Auswirkungen der oben genannten CVEs finden Sie in den Sicherheitsbulletins.

Welche Sicherheitslücken werden mit diesem Patch behoben?

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, und CVE-2022-21656
Hoch

GCP-2022-006

Veröffentlicht: 2022-02-14
Zuletzt aktualisiert: 2022-02-17

GKE

Beschreibung Schweregrad

In der Funktion cgroup_release_agent_write des Linux-Kernels wurde eine Sicherheitslücke, CVE-2022-0492, entdeckt. Der Angriff verwendet nicht privilegierte Nutzer-Namespaces und unter bestimmten Umständen kann diese Sicherheitslücke für Container-Breakouts ausgenutzt werden.

Was soll ich tun?

Aktualisierung vom 15.02.2022: Korrektur der gVisor-Anweisung.

Die Sicherheitslücke befindet sich im cgroup_release_agent_write des Linux-Kernels in der Funktion kernel/cgroup/cgroup-v1.c und kann als Container-Aufschlüsselung verwendet werden. GKE ist vom Schutz des standardmäßigen AppArmor-Profils in Ubuntu und COS nicht betroffen. Einige Kunden sind jedoch möglicherweise anfällig, wenn sie durch die Änderung des Felds "securityContext" des Pods oder Containers die Sicherheitsbeschränkungen für Pods gelockert haben. z. B. durch Deaktivieren/Ändern des AppArmor-Profils, was nicht empfohlen wird. Zusätzlich zum standardmäßigen AppArmor-Profil schützen diese Funktionen auch vor der Sicherheitslücke:

  • GKE Autopilot ist aufgrund des standardmäßigen seccomp-Profils nicht betroffen.
  • Aktualisierung vom 15.02.2022: gVisor (GKE Sandbox) ist nicht betroffen, da gVisor keinen Zugriff auf das anfällige Systemaufruf auf dem Host zulässt.

Patches werden in einer künftigen Version verfügbar sein. Dieses Bulletin wird aktualisiert, sobald sie verfügbar sind.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2022-0492

Niedrig

Anthos-Cluster

Beschreibung Schweregrad

In der Funktion cgroup_release_agent_write des Linux-Kernels wurde eine Sicherheitslücke, CVE-2022-0492, entdeckt. Der Angriff verwendet nicht privilegierte Nutzer-Namespaces und unter bestimmten Umständen kann diese Sicherheitslücke für Container-Breakouts ausgenutzt werden.

Was soll ich tun?

Die Sicherheitslücke befindet sich im cgroup_release_agent_write des Linux-Kernels in der Kernel/cgroup/cgroup-v1.c-Funktion und kann als Container-Aufschlüsselung verwendet werden. Anthos-Cluster auf VMware sind aufgrund des Schutzes vom standardmäßigen AppArmor-Profil unter Ubuntu und COS nicht betroffen. Einige Kunden sind jedoch möglicherweise anfällig, wenn sie durch die Änderung des Pod- oder Container-SecurityContext gelockerte Sicherheitsbeschränkungen für Pods haben, z. B. durch Deaktivieren/Ändern des AppArmor-Profils, was nicht empfohlen wird.

Patches werden in einer künftigen Version verfügbar sein. Dieses Bulletin wird aktualisiert, sobald sie verfügbar sind.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2022-0492

Niedrig

Anthos

Beschreibung Schweregrad

In der Funktion cgroup_release_agent_write des Linux-Kernels wurde eine Sicherheitslücke, CVE-2022-0492, entdeckt. Der Angriff verwendet nicht privilegierte Nutzer-Namespaces und unter bestimmten Umständen kann diese Sicherheitslücke für Container-Breakouts ausgenutzt werden.

Was soll ich tun?

Anthos in Azure ist aufgrund des Schutzes vom AppArmor-Standardprofil unter Ubuntu nicht betroffen. Einige Kunden sind jedoch möglicherweise anfällig, wenn sie durch die Änderung des Pod- oder Container-Sicherheitskontextfelds Sicherheitsbeschränkungen für Pods gelockert haben, z. B. durch Deaktivieren/Ändern des AppArmor-Profils, was nicht empfohlen wird.

Patches werden in einer künftigen Version verfügbar sein. Dieses Bulletin wird aktualisiert, sobald sie verfügbar sind.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2022-0492

Niedrig

GCP-2022-005

Veröffentlicht: 11.02.2022
Aktualisiert: 15.02.2022
Referenz: CVE-2021-43527

GKE

Beschreibung Schweregrad
Aktualisierung vom 15.02.2022: Einige GKE-Versionen im ursprünglichen Bulletin wurden mit anderen Fehlerkorrekturen kombiniert und ihre Versionsnummern wurden vor der Veröffentlichung erhöht. Patches sind in den folgenden GKE-Versionen verfügbar:
  • 1.20.15-gke.300
  • 1.21.9-gke.300
  • 1.22.6-gke.1000

Es wurde eine Sicherheitslücke, CVE-2021-43527, in einer beliebigen Binärdatei entdeckt, die auf die anfälligen Versionen von libnss3 in Versionen von NSS (Network Security Services) vor 3.73 oder 3.68.1 verweist. Anwendungen, die NSS für die Zertifikatsprüfung oder andere TLS-, X.509-, OCSP- oder CRL-Funktionen verwenden, können abhängig davon, wie NSS verwendet/konfiguriert wird, betroffen sein. Sowohl auf GKE-COS- als auch auf Ubuntu-Images ist eine anfällige Version installiert, die gepatcht werden muss.

CVE-2021-43527 kann weitreichende Auswirkungen auf Anwendungen haben, die NSS zur Verarbeitung von Signaturen verwenden, die in CMS, S/MIME, PKCS#7 oder PKCS#12 codiert sind. Sowie Anwendungen, die NSS für die Zertifikatsprüfung oder andere TLS-, X.509-, OCSP- oder CRL-Funktionen verwenden. Die Auswirkungen hängen davon ab, wie NSS verwendet/konfiguriert wird.

GKE verwendet libnss3 nicht für über das Internet zugängliche APIs. Die Auswirkungen sind auf den Hostcode beschränkt, der außerhalb von Containern ausgeführt wird. Dies ist aufgrund des minimalen Designs von Chrome OS klein. GKE-Code, der in Containern mit dem Basis-Image "golang" ausgeführt wird, ist nicht betroffen.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Führen Sie ein Upgrade Ihrer Steuerungsebene und Knoten auf eine der folgenden GKE-Versionen durch:

  • 1.18-Version noch nicht bekannt
  • 1.19.16-gke.6100
  • 1.20.15-gke.200
  • 1.21.9-gke.200
  • 1.22.6-gke.600
  • 1.23.3-gke.500
Verwenden Sie eine GKE-Version vor 1.18? Sie verwenden eine GKE-Version aus SLA und sollten auf eine der unterstützten Versionen aktualisieren.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2021-43527

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Es wurde eine Sicherheitslücke, CVE-2021-43527, in einer beliebigen Binärdatei entdeckt, die auf die anfälligen Versionen von libnss3 in Versionen von NSS (Network Security Services) vor 3.73 oder 3.68.1 verweist. Anwendungen, die NSS für die Zertifikatsprüfung oder andere TLS-, X.509-, OCSP- oder CRL-Funktionen verwenden, können, abhängig davon, wie sie NSS konfigurieren, betroffen sein. Auf Anthos-Cluster auf VMware-COS- und Ubuntu-Images ist eine anfällige Version installiert, die gepatcht werden muss.

CVE-2021-43527 kann weitreichende Auswirkungen auf Anwendungen haben, die NSS zur Verarbeitung von Signaturen verwenden, die in CMS, S/MIME, PKCS \#7 oder PKCS \#12 codiert sind. Sowie Anwendungen, die NSS für die Zertifikatsprüfung oder andere TLS-, X.509-, OCSP- oder CRL-Funktionen verwenden. Die Auswirkungen hängen davon ab, wie sie NSS konfigurieren/verwenden. Anthos on VMware verwendet libnss3 nicht für öffentlich zugängliche APIs. Daher sind die Auswirkungen begrenzt und der Schweregrad dieses CVEs für Anthos-Cluster auf VMware wird als Mittel bewertet.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden Anthos-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Führen Sie ein Upgrade Ihrer Steuerungsebene und Knoten auf eine der folgenden Anthos-Versionen durch:

  • 1.8.7
  • 1.9.4
  • 1.10.2

Verwenden Sie Anthos clusters on VMware-Version vor 1.18? Sie verwenden eine Anthos-Version ohne SLA und sollten ein Upgrade auf eine der unterstützten Versionen in Betracht ziehen.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2021-43527

Mittel

Anthos

Beschreibung Schweregrad

Es wurde eine Sicherheitslücke, CVE-2021-43527, in einer beliebigen Binärdatei entdeckt, die auf die anfälligen Versionen von libnss3 in Versionen von NSS (Network Security Services) vor 3.73 oder 3.68.1 verweist. Anwendungen, die NSS für die Zertifikatsprüfung oder andere TLS-, X.509-, OCSP- oder CRL-Funktionen verwenden, können abhängig davon, wie NSS verwendet/konfiguriert wird, betroffen sein. Bei Anthos-Clustern auf Azure-Ubuntu-Images ist eine anfällige Version installiert, die gepatcht werden muss.

CVE-2021-43527 kann weitreichende Auswirkungen auf Anwendungen haben, die NSS zur Verarbeitung von Signaturen verwenden, die in CMS, S/MIME, PKCS#7 oder PKCS#12 codiert sind. Sowie Anwendungen, die NSS für die Zertifikatsprüfung oder andere TLS-, X.509-, OCSP- oder CRL-Funktionen verwenden. Die Auswirkungen hängen davon ab, wie sie NSS konfigurieren/verwenden. Anthos-Cluster in Azure verwenden libnss3 nicht für öffentlich zugängliche APIs. Daher sind die Auswirkungen begrenzt und der Schweregrad dieser CVEs für Anthos in Azure wird als "Mittel" bewertet.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos on Azure wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Aktualisieren Sie Ihre Cluster auf eine der folgenden Anthos-on-Azure-Versionen:

  • v1.21.6-gke.1500

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2021-43527

Mittel

GCP-2022-004

Veröffentlicht: 2022-02-04
Referenz: CVE-2021-4034

GKE

Beschreibung Schweregrad

In pkexec, einem Teil des Linux-Policy-Kits (polkit), wurde die Sicherheitslücke CVE-2021-4034 erkannt, die einem authentifizierten Nutzer die Ausführung eines Angriffs nach Rechteausweitung ermöglicht. PolicyKit wird im Allgemeinen nur auf Linux-Desktopsystemen verwendet, um Nicht-Root-Nutzer Aktionen wie das Neustarten des Systems, das Installieren von Paketen, das Neustarten von Diensten usw. gemäß einer Richtlinie zu ermöglichen.

Was soll ich tun?

GKE ist nicht betroffen, da das anfällige Modul "policykit-1" nicht auf COS- oder Ubuntu-Images installiert wird, die in GKE verwendet werden. Sie müssen nichts unternehmen.

Anthos-Cluster

Beschreibung Schweregrad

In pkexec, einem Teil des Linux-Policy-Kits (polkit), wurde die Sicherheitslücke CVE-2021-4034 erkannt, die einem authentifizierten Nutzer die Ausführung eines Angriffs nach Rechteausweitung ermöglicht. PolicyKit wird im Allgemeinen nur auf Linux-Desktopsystemen verwendet, um Nicht-Root-Nutzer Aktionen wie das Neustarten des Systems, das Installieren von Paketen, das Neustarten von Diensten usw. gemäß einer Richtlinie zu ermöglichen.

Die Anthos-Standardkonfiguration gewährt Nutzern bereits vollständige "sudo"-Berechtigungen, sodass dieser Exploit den vorhandenen Sicherheitsstatus von Anthos nicht ändert

Technische Details

Damit dieser Programmfehler ausgenutzt werden kann, benötigt ein Angreifer sowohl eine Nicht-Root-Shell im Knotendateisystem als auch die anfällige pkexec-Version. Anthos-Cluster auf VMware umfasst zwar eine Version von policykit-1 in den zugehörigen Release-Images, doch die Anthos-Standardkonfiguration bietet bereits allen Nutzern mit Shell-Zugriff passwortlose "sudo"-Rechte, sodass diese Sicherheitslücke keine weiteren Berechtigungen erteilt.

Was soll ich tun?

Sie müssen nichts unternehmen. Anthos-Cluster auf VMware ist nicht betroffen.

Anthos-Cluster

Beschreibung Schweregrad
Anthos-Cluster in AWS ist nicht betroffen. Das anfällige Modul "policykit-1" ist nicht auf Ubuntu-Images installiert, die von den aktuellen und früheren Versionen von Anthos-Cluster in AWS verwendet werden.

Anthos

Beschreibung Schweregrad

In pkexec, einem Teil des Linux-Policy-Kits (polkit), wurde die Sicherheitslücke CVE-2021-4034 erkannt, die einem authentifizierten Nutzer die Ausführung eines Angriffs nach Rechteausweitung ermöglicht. PolicyKit wird im Allgemeinen nur auf Linux-Desktopsystemen verwendet, um Nicht-Root-Nutzer Aktionen wie das Neustarten des Systems, das Installieren von Paketen, das Neustarten von Diensten usw. gemäß einer Richtlinie zu ermöglichen.

Die Anthos-Standardkonfiguration gewährt Nutzern bereits vollständige "sudo"-Berechtigungen, sodass dieser Exploit den vorhandenen Sicherheitsstatus von Anthos nicht ändert

Technische Details

Damit dieser Programmfehler ausgenutzt werden kann, benötigt ein Angreifer sowohl eine Nicht-Root-Shell im Knotendateisystem als auch die anfällige pkexec-Version. Anthos on Azure umfasst zwar eine Version von policykit-1 in den zugehörigen Release-Images, doch die Anthos-Standardkonfiguration bietet bereits allen Nutzern mit Shell-Zugriff passwortlose "sudo"-Rechte, sodass diese Sicherheitslücke keine weiteren Berechtigungen erteilt.

Was soll ich tun?

Sie müssen nichts unternehmen. Anthos on Azure ist nicht betroffen.

Anthos-Cluster

Beschreibung Schweregrad
Anthos auf Bare-Metal kann abhängig von Paketen betroffen sein, die auf dem vom Kunden verwalteten Betriebssystem installiert sind. Scannen Sie Ihre Betriebssystem-Images und patchen Sie sie bei Bedarf.

GCP-2022-002

Veröffentlicht: 01.02.2022
Zuletzt aktualisiert: 03.07.2022
Referenz:
CVE-2021-4154, CVE-2021-22600, CVE-2022-0185
Aktualisierung vom 04.02.2022: Abschnitte für Anthos-Cluster in AWS und Anthos in Azure hinzugefügt. Es wurden Rollout-Updates für GKE- und Anthos-Cluster auf VMware hinzugefügt.

GKE

Aktualisiert: 07.03.2022

Beschreibung Schweregrad

Drei Sicherheitslücken, CVE-2021-4154, CVE-2021-22600 und CVE-2022-0185, wurden im Linux-Kernel erkannt, von der jede zu einem Container-Breakout, einer Rechteausweitung auf dem Host oder zu beidem führen kann. Diese Sicherheitslücken betreffen alle Knotenbetriebssysteme (COS und Ubuntu) in GKE, Anthos-Cluster auf VMware, Anthos-Cluster in AWS (aktuelle und vorherige Generation) und Anthos on Azure.

Pods, die GKE Sandbox verwenden, sind nicht anfällig für diese Sicherheitslücken.

Weitere Informationen finden Sie in den COS-Versionshinweisen.

Technische Details

In CVE-2021-4154 kann ein Angreifer den Systemaufrufparameter fsconfig ausnutzen, um im Linux-Kernel einen Use-after-Free-Programmfehler auszulösen, was zu Root-Berechtigungen führt. Dies ist ein lokaler Angriffspunkt zur Rechteausweitung, der zu einem Containerausfall führt.

CVE-2021-22600 ist ein doppelter kostenloser Exploit in package_set_ring, der zu einem Container-Escape auf dem Host-Knoten führen kann.

Bei CVE-2022-0185 kann ein Heap-Überlauffehler in legacy_parse_param() zu einem Schreibvorgang außerhalb des Bereichs führen, der einen Container-Breakout verursacht.

Der Exploit-Pfad für diese Sicherheitslücke, die auf dem Systemaufruf "Unshare" basiert, wird in GKE Autopilot-Clustern standardmäßig mithilfe von seccomp-Filterung blockiert.

Nutzer, die das standardmäßige seccomp-Profil der Containerlaufzeit manuell auf GKE-Standardclustern aktiviert haben, sind ebenfalls geschützt.

Was soll ich tun?

Aktualisierung vom 7. März 2022: Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um alle diese Sicherheitslücken sowohl für Ubuntu- als auch für COS-Images zu beheben. Führen Sie ein Upgrade Ihrer Steuerungsebene und Knoten auf eine der folgenden GKE-Versionen durch:

  • 1.18.20-gke.6101
  • 1.19.16-gke.8300
  • 1.20.15-gke.2500
  • 1.21.10-gke.400
  • 1.22.7-gke.900
  • 1.23.3-gke.1100

Aktualisierung vom 25. Februar 2022: Wenn Sie Ubuntu-Knoten-Images verwenden, reagiert 1.22.6-gke.1000 nicht auf CVE-2021-22600. Wir aktualisieren dieses Bulletin, sobald die Ubuntu-Patchversionen verfügbar sind.


Aktualisierung vom 23.02.2022: Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Aktualisieren Sie Ihre Cluster auf eine der folgenden GKE-Versionen.

  • 1.18.20-gke.6101
  • 1.22.6-gke.1000
  • 1.23.3-gke.1100

Aktualisierung vom 04.02.2022: Das Roll-out-Startdatum für GKE-Patchversionen war am 2. Februar.


Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden GKE-Versionen.

  • 1.19.16-gke.6100
  • 1.20.15-gke.300
  • 1.21.9-gke.300

Außerdem werden die Versionen 1.22 und 1.23 ausgeführt. Wir aktualisieren dieses Bulletin, sobald sie verfügbar sind.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Hoch

Anthos-Cluster

Zuletzt aktualisiert: 23.02.2022

Beschreibung Schweregrad

Drei Sicherheitslücken, CVE-2021-4154, CVE-2021-22600 und CVE-2022-0185, wurden im Linux-Kernel erkannt, von der jede zu einem Container-Breakout, einer Rechteausweitung auf dem Host oder zu beidem führen kann. Diese Sicherheitslücken betreffen alle Knotenbetriebssysteme (COS und Ubuntu) in GKE, Anthos-Cluster auf VMware, Anthos-Cluster in AWS (aktuelle und vorherige Generation) und Anthos on Azure.

Weitere Informationen finden Sie in den COS-Versionshinweisen.

Technische Details

In CVE-2021-4154 kann ein Angreifer den Systemaufrufparameter fsconfig ausnutzen, um im Linux-Kernel einen Use-after-Free-Programmfehler auszulösen, was zu Root-Berechtigungen führt. Dies ist ein lokaler Angriffspunkt zur Rechteausweitung, der zu einem Containerausfall führt.

CVE-2021-22600 ist ein doppelter kostenloser Exploit in package_set_ring, der zu einem Container-Escape auf dem Host-Knoten führen kann.

Bei CVE-2022-0185 kann ein Heap-Überlauffehler in legacy_parse_param() zu einem Schreibvorgang außerhalb des Bereichs führen, der einen Container-Breakout verursacht.

Nutzer, die das standardmäßige seccomp-Profil der Containerlaufzeit manuell auf GKE-Standardclustern aktiviert haben, sind ebenfalls geschützt.

Was soll ich tun?

Aktualisierung vom 23. Februar 2022: Version 1.10.2 (Korrekturen von CVE-2021-22600, CVE-2021-4154 und CVE-2022-0185) ist jetzt für den 1. März geplant.

Aktualisierung vom 23.02.2022: Patchversionen wurden hinzugefügt, die auf CVE-2021-2260 reagieren.

Version 1.10.1 behebt nicht CVE-2021-22600, sondern die anderen Sicherheitslücken. Die nicht freigegebenen Versionen 1.9.4 und 1.10.2 beheben CVE-2021-22600. Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos-Clustern on VMware wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Führen Sie ein Upgrade Ihrer Cluster auf einen der folgenden Versionen von Anthos-Cluster on VMware durch:

  • 1.10.1 (behebt CVE-2021-4154 und CVE-2022-0185. Veröffentlicht am 10. Februar)
  • 1.8.7 (behebt CVE-2021-22600, CVE-2021-4154 und CVE-2022-0185. Veröffentlicht am 17. Februar)
  • 1.9.4 (behebt CVE-2021-22600, CVE-2021-4154 und CVE-2022-0185). Veröffentlicht am 23. Februar)
  • 1.10.2 (behebt CVE-2021-22600, CVE-2021-4154 und CVE-2022-0185. (geplant für den 24. Februar)

Aktualisierung vom 04.02.2022: Es wurden Informationen zu Ubuntu-Images hinzugefügt, die CVE-2021-22600 nicht berücksichtigen.

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos-Clustern on VMware wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Führen Sie ein Upgrade Ihrer Cluster auf einen der folgenden Versionen von Anthos-Cluster on VMware durch:

  • 1.10.1 (nur COS-Update. Ubuntu-Patch ist ab dem 23. Februar in 1.10.2)
  • 1.9.4 (geplant für 15. Februar)
  • 1.8.7 (geplant für 15. Februar)

Welche Sicherheitslücke wird mit diesem Patch behoben?

Hoch

Anthos-Cluster

Beschreibung Schweregrad

Drei Sicherheitslücken, CVE-2021-4154, CVE-2021-22600 und CVE-2022-0185, wurden im Linux-Kernel erkannt, von der jede zu einem Container-Breakout, einer Rechteausweitung auf dem Host oder zu beidem führen kann. Diese Sicherheitslücken betreffen alle Knotenbetriebssysteme (COS und Ubuntu) in GKE, Anthos-Cluster auf VMware, Anthos-Cluster in AWS (aktuelle und vorherige Generation) und Anthos on Azure.

Weitere Informationen finden Sie in den COS-Versionshinweisen.

Technische Details

In CVE-2021-4154 kann ein Angreifer den Systemaufrufparameter fsconfig ausnutzen, um im Linux-Kernel einen Use-after-Free-Programmfehler auszulösen, was zu Root-Berechtigungen führt. Dies ist ein lokaler Angriffspunkt zur Rechteausweitung, der zu einem Containerausfall führt.

CVE-2021-22600 ist ein doppelter kostenloser Exploit in package_set_ring, der zu einem Container-Escape auf dem Host-Knoten führen kann.

Bei CVE-2022-0185 kann ein Heap-Überlauffehler in legacy_parse_param() zu einem Schreibvorgang außerhalb des Bereichs führen, der einen Container-Breakout verursacht.

Nutzer, die das standardmäßige seccomp-Profil der Containerlaufzeit manuell auf GKE-Standardclustern aktiviert haben, sind ebenfalls geschützt.

Was soll ich tun?

Anthos-Cluster in AWS

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos-Cluster on AWS wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Aktualisieren Sie Ihre Cluster auf die folgende Version von Anthos-Cluster on AWS:

  • 1.21.6-gke.1500 und höher (verfügbar im Februar)

Anthos-Cluster in AWS (vorherige Generation)

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos-Cluster on AWS (vorherige Generation) wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Führen Sie ein Upgrade Ihrer Cluster auf eine der folgenden Anthos-Cluster on AWS-Versionen (vorherige Generation) durch:

  • 1.19.16-gke.5300
  • 1.20.14-gke.2000
  • 1.21.8-gke.2000

Welche Sicherheitslücke wird mit diesem Patch behoben?

Hoch

Anthos

Beschreibung Schweregrad

Drei Sicherheitslücken, CVE-2021-4154, CVE-2021-22600 und CVE-2022-0185, wurden im Linux-Kernel erkannt, von der jede zu einem Container-Breakout, einer Rechteausweitung auf dem Host oder zu beidem führen kann. Diese Sicherheitslücken betreffen alle Knotenbetriebssysteme (COS und Ubuntu) in GKE, Anthos-Cluster auf VMware, Anthos-Cluster in AWS (aktuelle und vorherige Generation) und Anthos on Azure.

Weitere Informationen finden Sie in den COS-Versionshinweisen.

Technische Details

In CVE-2021-4154 kann ein Angreifer den Systemaufrufparameter fsconfig ausnutzen, um im Linux-Kernel einen Use-after-Free-Programmfehler auszulösen, was zu Root-Berechtigungen führt. Dies ist ein lokaler Angriffspunkt zur Rechteausweitung, der zu einem Containerausfall führt.

CVE-2021-22600 ist ein doppelter kostenloser Exploit in package_set_ring, der zu einem Container-Escape auf dem Host-Knoten führen kann.

Bei CVE-2022-0185 kann ein Heap-Überlauffehler in legacy_parse_param() zu einem Schreibvorgang außerhalb des Bereichs führen, der einen Container-Breakout verursacht.

Nutzer, die das standardmäßige seccomp-Profil der Containerlaufzeit manuell auf GKE-Standardclustern aktiviert haben, sind ebenfalls geschützt.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden Versionen von Anthos on Azure wurden mit Code aktualisiert, um diese Sicherheitslücken zu beheben. Aktualisieren Sie Ihre Cluster auf die folgende Version von Anthos on Azure:

  • 1.21.6-gke.1500 und höher (verfügbar im Februar)

Welche Sicherheitslücke wird mit diesem Patch behoben?

Hoch

GCP-2021-024

Veröffentlicht: 2021-10-21
Referenz: CVE-2021-25742

GKE

Beschreibung Schweregrad

Im Kubernetes-Controller Ingress-nginx wurde das Sicherheitsproblem CVE-2021-25742 festgestellt. Benutzerdefinierte Snippets für Ingress-nginx ermöglichen das Abrufen von Tokens und Secrets für Ingress-nginx in allen Namespaces.

Was soll ich tun?

Dieses Sicherheitsproblem hat keine Auswirkungen auf die GKE-Clusterinfrastruktur oder die Clusterinfrastruktur von Anthos-Umgebungen. Wenn Sie in Ihren Arbeitslastbereitstellungen Ingress-nginx verwenden, sollten Sie sich mit diesem Sicherheitsproblem vertraut machen. Weitere Informationen finden Sie unter Ingress-nginx-Problem 7837.

Anthos-Cluster

Beschreibung Schweregrad

Im Kubernetes-Controller Ingress-nginx wurde das Sicherheitsproblem CVE-2021-25742 festgestellt. Benutzerdefinierte Snippets für Ingress-nginx ermöglichen das Abrufen von Tokens und Secrets für Ingress-nginx in allen Namespaces.

Was soll ich tun?

Dieses Sicherheitsproblem hat keine Auswirkungen auf die GKE-Clusterinfrastruktur oder die Clusterinfrastruktur von Anthos-Umgebungen. Wenn Sie in Ihren Arbeitslastbereitstellungen Ingress-nginx verwenden, sollten Sie sich mit diesem Sicherheitsproblem vertraut machen. Weitere Informationen finden Sie unter Ingress-nginx-Problem 7837.

Anthos-Cluster

Beschreibung Schweregrad

Im Kubernetes-Controller Ingress-nginx wurde das Sicherheitsproblem CVE-2021-25742 festgestellt. Benutzerdefinierte Snippets für Ingress-nginx ermöglichen das Abrufen von Tokens und Secrets für Ingress-nginx in allen Namespaces.

Was soll ich tun?

Dieses Sicherheitsproblem hat keine Auswirkungen auf die GKE-Clusterinfrastruktur oder die Clusterinfrastruktur von Anthos-Umgebungen. Wenn Sie in Ihren Arbeitslastbereitstellungen Ingress-nginx verwenden, sollten Sie sich mit diesem Sicherheitsproblem vertraut machen. Weitere Informationen finden Sie unter Ingress-nginx-Problem 7837.

Anthos-Cluster

Beschreibung Schweregrad

Im Kubernetes-Controller Ingress-nginx wurde das Sicherheitsproblem CVE-2021-25742 festgestellt. Benutzerdefinierte Snippets für Ingress-nginx ermöglichen das Abrufen von Tokens und Secrets für Ingress-nginx in allen Namespaces.

Was soll ich tun?

Dieses Sicherheitsproblem hat keine Auswirkungen auf die GKE-Clusterinfrastruktur oder die Clusterinfrastruktur von Anthos-Umgebungen. Wenn Sie in Ihren Arbeitslastbereitstellungen Ingress-nginx verwenden, sollten Sie sich mit diesem Sicherheitsproblem vertraut machen. Weitere Informationen finden Sie unter Ingress-nginx-Problem 7837.

GCP-2021-019

Veröffentlicht: 2021-09-29

GKE

Beschreibung Schweregrad

Es gibt ein bekanntes Problem, bei dem eine BackendConfig-Ressource mithilfe der v1beta1 API aktualisiert wird, die eine aktive Google Cloud Armor-Sicherheitsrichtlinie aus dem Dienst entfernt.

Bin ich betroffen?

Wenn Ihre BackendConfig bereits mit der v1beta1 API aktualisiert wurde, wurde Ihre Google Cloud Armor-Sicherheitsrichtlinie möglicherweise entfernt. Führen Sie den folgenden Befehl aus, um festzustellen, ob dies der Fall ist:


kubectl get backendconfigs -A -o json | \
jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'
  • Wenn die Antwort eine Ausgabe zurückgibt: Ihr Cluster ist von diesem Problem betroffen. Die Ausgabe dieses Befehls gibt eine Liste der BackendConfig-Ressourcen zurück (<namespace>/<name>), die von dem Problem betroffen sind.
  • Wenn die Ausgabe leer ist: Ihre BackendConfig wurde seit dem Auftreten des Problems nicht mit der v1beta1 API aktualisiert. Alle zukünftigen Updates Ihrer BackendConfig sollten nur v1 verwenden.

Dieses Problem betrifft die folgenden GKE-Versionen:

  • 1.18.19-gke.1400 bis 1.18.20-gke.5100 (ausschließlich)
  • 1.19.10-gke.700 bis 1.19.14-gke.300 (ausschließlich)
  • 1.20.6-gke.700 bis 1.20.9-gke.900 (ausschließlich)
  • 1.21 to 1.21.1-gke.2700 (ausschließlich)

Wenn Sie Google Cloud Armor für Ihre Ingress-Ressourcen nicht über die BackendConfig konfigurieren, sind Ihre Cluster von diesem Problem nicht betroffen.

Was soll ich tun?

Führen Sie ein Upgrade Ihrer GKE-Steuerungsebene auf eine der folgenden aktualisierten Versionen durch, in denen dieses Problem behoben wurde und die sichere Verwendung von v1beta1-BackendConfig-Ressourcen möglich ist.

  • 1.21.1-gke.2700 und höher
  • 1.20.9-gke.900 und höher
  • 1.19.14-gke.300 und höher
  • 1.18.20-gke.5100 und höher

Sie können dieses Problem auch verhindern, indem Sie die Bereitstellung von v1beta1-BackendConfig-Ressourcen vermeiden. Wenn Sie Google Cloud Armor über BackendConfig auf Ihren Ingress-Ressourcen konfigurieren und feststellen, dass Sie von den obigen Schritten betroffen sind, aktivieren Sie Google Cloud Armor wieder, indem Sie ein Update auf Ihre aktuelle BackendConfig-Ressource mit der API-Version cloud.google.com/v1 übertragen.

Um dieses Problem zu vermeiden, aktualisieren Sie Ihre BackendConfig nur mithilfe der v1 BackendConfig API.

Da die BackendConfig v1 dieselben Felder wie v1beta1 unterstützt und keine funktionsgefährdenden Änderungen vornimmt, kann das API-Feld transparent aktualisiert werden. Dazu ersetzen Sie das Feld apiVersion eines beliebigen BackendConfig-Manifests durch cloud.google.com/v1. Verwenden Sie nicht cloud.google.com/v1beta1.

Das folgende Beispielmanifest beschreibt eine BackendConfig-Ressource, die die v1 API verwendet:


apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backend-config
spec:
  securityPolicy:
    name: "ca-how-to-security-policy"

Wenn Sie CI/CD-Systeme oder -Tools haben, die regelmäßig BackendConfig-Ressourcen aktualisieren, achten Sie darauf, dass Sie die API-Gruppe cloud.google.com/v1 in diesen Systemen verwenden.

Niedrig

GCP-2021-022

Veröffentlicht: 23.09.2021

Anthos-Cluster

Beschreibung Schweregrad

Im AIS-LDAP-Modul (Anthos Identity Service) von Anthos-Cluster auf VMware-Versionen 1.8 und 1.8.1 wurde eine Sicherheitslücke entdeckt, bei der ein Quellschlüssel zum Generieren von Schlüsseln vorhersehbar ist. Mit dieser Sicherheitslücke könnte ein authentifizierter Nutzer beliebige Anforderungen hinzufügen und Berechtigungen auf unbestimmte Zeit eskalieren.

Technische Details

Eine kürzlich hinzugefügte Ergänzung für AIS-Code erstellt symmetrische Schlüssel mit dem "math/rand"-Modul von Golang, das für sicherheitsrelevanten Code nicht geeignet ist. Das Modul wird so verwendet, dass ein vorhersehbarer Schlüssel generiert wird. Während der Identitätsüberprüfung wird ein STS-Schlüssel (Secure Token Service) generiert, der anschließend mit einem einfach abzuleitenden symmetrischen Schlüssel verschlüsselt wird.

Was soll ich tun?

Diese Sicherheitslücke betrifft nur Kunden, die AIS in Anthos-Cluster auf VMware-Versionen 1.8 und 1.8.1 verwenden. Für Nutzer von Anthos-Cluster auf VMware 1.8 führen Sie ein Upgrade Ihrer Cluster auf die folgende Version aus:

  • 1.8.2
Hoch

GCP-2021-021

Veröffentlicht: 22.09.2021
Referenz: CVE-2020-8561

GKE

Beschreibung Schweregrad

Bei Kubernetes wurde die Sicherheitslücke CVE-2020-8561 erkannt, bei der bestimmte Webhooks erstellt werden können, um kube-apiserver-Anfragen an private Netzwerke dieses API-Servers weiterzuleiten.

Technische Details

Durch diese Sicherheitslücke können Nutzer, die die Antworten von MutatingWebhookConfiguration- oder ValidatingWebhookConfiguration-Anfragen steuern, kube-apiserver-Anfragen an private Netzwerke des API-Servers weiterleiten. Wenn dieser Nutzer kube-apiserver-Logs aufrufen kann, wenn die Logebene auf 10 festgelegt ist, kann der Nutzer die weitergeleiteten Antworten und Header in den Logs sehen.

Dieses Problem lässt sich beheben, indem bestimmte Parameter für den API-Server geändert werden.

Was soll ich tun?

Momentan müssen Sie nichts weiter tun.

In den derzeit verfügbaren Versionen von GKE und Anthos sind die folgenden Schutzmaßnahmen implementiert, die vor dieser Art von Angriffen schützen:

  • Das Flag --profiling für kube-apiserver ist auf false gesetzt.
  • Die Logebene kube-apiserver ist auf einen Wert unter 10 festgelegt.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2020-8561

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Bei Kubernetes wurde die Sicherheitslücke CVE-2020-8561 erkannt, bei der bestimmte Webhooks erstellt werden können, um kube-apiserver-Anfragen an private Netzwerke dieses API-Servers weiterzuleiten.

Technische Details

Durch diese Sicherheitslücke können Nutzer, die die Antworten von MutatingWebhookConfiguration- oder ValidatingWebhookConfiguration-Anfragen steuern, kube-apiserver-Anfragen an private Netzwerke des API-Servers weiterleiten. Wenn dieser Nutzer kube-apiserver-Logs aufrufen kann, wenn die Logebene auf 10 festgelegt ist, kann der Nutzer die weitergeleiteten Antworten und Header in den Logs sehen.

Dieses Problem lässt sich beheben, indem bestimmte Parameter für den API-Server geändert werden.

Was soll ich tun?

Momentan müssen Sie nichts weiter tun.

In den derzeit verfügbaren Versionen von GKE und Anthos sind die folgenden Schutzmaßnahmen implementiert, die vor dieser Art von Angriffen schützen:

  • Das Flag --profiling für kube-apiserver ist auf false gesetzt.
  • Die Logebene kube-apiserver ist auf einen Wert unter 10 festgelegt.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2020-8561

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Bei Kubernetes wurde die Sicherheitslücke CVE-2020-8561 erkannt, bei der bestimmte Webhooks erstellt werden können, um kube-apiserver-Anfragen an private Netzwerke dieses API-Servers weiterzuleiten.

Technische Details

Durch diese Sicherheitslücke können Nutzer, die die Antworten von MutatingWebhookConfiguration- oder ValidatingWebhookConfiguration-Anfragen steuern, kube-apiserver-Anfragen an private Netzwerke des API-Servers weiterleiten. Wenn dieser Nutzer kube-apiserver-Logs aufrufen kann, wenn die Logebene auf 10 festgelegt ist, kann der Nutzer die weitergeleiteten Antworten und Header in den Logs sehen.

Dieses Problem lässt sich beheben, indem bestimmte Parameter für den API-Server geändert werden.

Was soll ich tun?

Momentan müssen Sie nichts weiter tun.

In den derzeit verfügbaren Versionen von GKE und Anthos sind die folgenden Schutzmaßnahmen implementiert, die vor dieser Art von Angriffen schützen:

  • Das Flag --profiling für kube-apiserver ist auf false gesetzt.
  • Die Logebene kube-apiserver ist auf einen Wert unter 10 festgelegt.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2020-8561

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Bei Kubernetes wurde die Sicherheitslücke CVE-2020-8561 erkannt, bei der bestimmte Webhooks erstellt werden können, um kube-apiserver-Anfragen an private Netzwerke dieses API-Servers weiterzuleiten.

Technische Details

Durch diese Sicherheitslücke können Nutzer, die die Antworten von MutatingWebhookConfiguration- oder ValidatingWebhookConfiguration-Anfragen steuern, kube-apiserver-Anfragen an private Netzwerke des API-Servers weiterleiten. Wenn dieser Nutzer kube-apiserver-Logs aufrufen kann, wenn die Logebene auf 10 festgelegt ist, kann der Nutzer die weitergeleiteten Antworten und Header in den Logs sehen.

Dieses Problem lässt sich beheben, indem bestimmte Parameter für den API-Server geändert werden.

Was soll ich tun?

Momentan müssen Sie nichts weiter tun.

In den derzeit verfügbaren Versionen von GKE und Anthos sind die folgenden Schutzmaßnahmen implementiert, die vor dieser Art von Angriffen schützen:

  • Das Flag --profiling für kube-apiserver ist auf false gesetzt.
  • Die Logebene kube-apiserver ist auf einen Wert unter 10 festgelegt.

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2020-8561

Mittel

GCP-2021-018

Veröffentlicht: 15.09.2021
Aktualisiert: 24.09.2021
Referenz: CVE-2021-25741

Aktualisierung vom 24.09.2021: Anthos-Cluster auf Bare-Metal-Bulletin mit zusätzlichen Patchversionen aktualisiert.

Aktualisierung vom 20.09.2021: Bulletins für Anthos-Cluster auf Bare Metal hinzugefügt

Aktualisierung vom 16.09.2021: Bulletins für Anthos-Cluster auf VMware hinzugefügt


GKE

Beschreibung Schweregrad

Ein Sicherheitsproblem in Kubernetes (CVE-2021-25741) wurde festgestellt, bei dem Nutzer möglicherweise einen Container mit Unterpfad-Volume-Bereitstellungen erstellen können, um auf Dateien und Verzeichnisse außerhalb des Volumes, z. B. im Hostdateisystem, zuzugreifen.

Technische Details:

In CVE-2021-25741 kann der Angreifer einen symbolischen Link von einem bereitgestellten emptyDir zum Root-Dateisystem des Knotens (/) erstellen. Das Kubelet folgt dem Symlink und stellt den Host-Root im Container bereit.

Was soll ich tun?

Wir empfehlen Ihnen, ein Upgrade Ihrer Knotenpools auf eine der folgenden Versionen oder höher durchzuführen, um die neuesten Patches zu nutzen:

  • 1.21.4-gke.301
  • 1.20.10-gke.301
  • 1.19.14-gke.301
  • 1.18.20-gke.4501

Die folgenden Versionen enthalten ebenfalls die Korrektur:

  • 1.21.3-gke.2001
  • 1.20.8-gke.2101
  • 1.20.9-gke.701
  • 1.20.9-gke.1001
  • 1.19.12-gke.2101
  • 1.19.13-gke.701
  • 1.18.20-gke.3001
Hoch

Anthos-Cluster

Beschreibung Schweregrad

Ein Sicherheitsproblem in Kubernetes (CVE-2021-25741) wurde festgestellt, bei dem Nutzer möglicherweise einen Container mit Unterpfad-Volume-Bereitstellungen erstellen können, um auf Dateien und Verzeichnisse außerhalb des Volumes, z. B. im Hostdateisystem, zuzugreifen.

Technische Details:

In CVE-2021-25741 kann der Angreifer einen symbolischen Link von einem bereitgestellten emptyDir zum Root-Dateisystem des Knotens (/) erstellen. Das Kubelet folgt dem Symlink und stellt den Host-Root im Container bereit.

Was soll ich tun?

Aktualisiert am 24.09.2021: Die Patchversionen 1.8.3 und 1.7.4 sind jetzt verfügbar.

Aktualisiert am 17.09.2021: Die Liste der verfügbaren Versionen, die den Patch enthalten, wurde korrigiert.


Die folgenden Versionen von Anthos-Cluster auf VMware wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Führen Sie ein Upgrade Ihrer Administratorcluster und Nutzercluster auf eine der folgenden Versionen durch:

  • 1.8.3
  • 1.8.2
  • 1.7.4
  • 1.6.5
Hoch

Anthos-Cluster

Beschreibung Schweregrad

Ein Sicherheitsproblem in Kubernetes (CVE-2021-25741) wurde festgestellt, bei dem Nutzer möglicherweise einen Container mit Unterpfad-Volume-Bereitstellungen erstellen können, um auf Dateien und Verzeichnisse außerhalb des Volumes, z. B. im Hostdateisystem, zuzugreifen.

Technische Details:

In CVE-2021-25741 kann der Angreifer einen symbolischen Link von einem bereitgestellten emptyDir zum Root-Dateisystem des Knotens (/) erstellen. Das Kubelet folgt dem Symlink und stellt den Host-Root im Container bereit.

Was soll ich tun?

Aktualisierung vom 16.09.2021: Liste der unterstützten gke-Versionen für AWSCluster- und AWSNodePool-Objekte hinzugefügt.


Die folgenden Versionen von Anthos-Cluster in AWS wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Wir empfehlen Folgendes:

  • Führen Sie ein Upgrade Ihrer AWSManagementService-, AWSCluster- und AWSNodePool-Objekte auf die folgende Version durch:
    • 1.8.2
  • Aktualisieren Sie die gke-Version Ihrer AWSCluster- und AWSNodePool-Objekte auf eine der unterstützten Kubernetes-Versionen:
    • 1.17.17-gke.15800
    • 1.18.20-gke.4800
    • 1.19.14-gke.600
    • 1.20.10-gke.600
Hoch

Anthos-Cluster

Beschreibung Schweregrad

Ein Sicherheitsproblem in Kubernetes (CVE-2021-25741) wurde festgestellt, bei dem Nutzer möglicherweise einen Container mit Unterpfad-Volume-Bereitstellungen erstellen können, um auf Dateien und Verzeichnisse außerhalb des Volumes, z. B. im Hostdateisystem, zuzugreifen.

Technische Details:

In CVE-2021-25741 kann der Angreifer einen symbolischen Link von einem bereitgestellten emptyDir zum Root-Dateisystem des Knotens (/) erstellen. Das Kubelet folgt dem Symlink und stellt den Host-Root im Container bereit.

Was soll ich tun?

Die folgenden Versionen von Anthos-Cluster auf Bare-Metal wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Führen Sie ein Upgrade Ihrer Administratorcluster und Nutzercluster auf eine der folgenden Versionen durch:

  • 1.8.3
  • 1.7.4
Hoch

GCP-2021-017

Veröffentlicht: 01.09.2021
Aktualisiert: 23.09.2021
Referenz: CVE-2021-33909
CVE-2021-33910

GKE

Beschreibung Schweregrad
Aktualisierung vom 23.09.2021:

Container, die in GKE Sandbox ausgeführt werden, sind von dieser Sicherheitslücke durch Angriffe aus dem Container nicht betroffen.


Aktualisierung vom 15.09.2021:

Die folgenden GKE-Versionen beheben die Sicherheitslücken:

  • 1.18.20-gke.4100
  • 1.19.13-gke.1900
  • 1.20.9-gke.1500
  • 1.21.3-gke.1400

Im Linux-Kernel wurden zwei Sicherheitslücken erkannt, CVE-2021-33909 und CVE-2021-33910, die zu einem Absturz des Betriebssystems oder einer Eskalation zum Root durch einen nicht privilegierten Nutzer führen können. Diese Sicherheitslücke betrifft alle GKE-Knotenbetriebssysteme (COS und Ubuntu).

Technische Details:

In CVE-2021-33909 beschränkt die Dateisystemebene des Linux-Kernels die Zwischenspeicherzuordnungen von Sequenzen nicht ordnungsgemäß, was zu einem Ganzzahlüberlauf, einem Schreibvorgang außerhalb des Bereichs und einer Eskalation zu root führt.
Durch CVE-2021-33910 hat systemd eine Speicherzuweisung mit einem übermäßigen Wert für die Größe (einschließlich strdupa und alloca für einen Pfadnamen, der von einem lokalen Angreifer gesteuert wird), was zu einem Betriebssystemabsturz führt.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für die folgenden GKE-Versionen wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden Versionen:

  • 1.18.20-gke.4100
  • 1.19.13-gke.1900
  • 1.20.9-gke.1500
  • 1.21.3-gke.1400
Hoch

Anthos-Cluster

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken erkannt, CVE-2021-33909 und CVE-2021-33910, die zu einem Absturz des Betriebssystems oder einer Eskalation zum Root durch einen nicht privilegierten Nutzer führen können. Diese Sicherheitslücke betrifft alle GKE-Knotenbetriebssysteme (COS und Ubuntu).

Technische Details:

In CVE-2021-33909 beschränkt die Dateisystemebene des Linux-Kernels die Zwischenspeicherzuordnungen von Sequenzen nicht ordnungsgemäß, was zu einem Ganzzahlüberlauf, einem Schreibvorgang außerhalb des Bereichs und einer Eskalation zu root führt.
Durch CVE-2021-33910 hat systemd eine Speicherzuweisung mit einem übermäßigen Wert für die Größe (einschließlich strdupa und alloca für einen Pfadnamen, der von einem lokalen Angreifer gesteuert wird), was zu einem Betriebssystemabsturz führt.

Was soll ich tun?

Die Versionen von Linux-Knoten-Images für Anthos-Cluster in AWS wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden Versionen:

  • 1.20.10-gke.600
  • 1.19.14-gke.600
  • 1.18.20-gke.4800
  • 1.17.17-gke.15800
Hoch

Anthos-Cluster

Beschreibung Schweregrad

Im Linux-Kernel wurden zwei Sicherheitslücken erkannt, CVE-2021-33909 und CVE-2021-33910, die zu einem Absturz des Betriebssystems oder einer Eskalation zum Root durch einen nicht privilegierten Nutzer führen können. Diese Sicherheitslücke betrifft alle GKE-Knotenbetriebssysteme (COS und Ubuntu).

Technische Details:

In CVE-2021-33909 beschränkt die Dateisystemebene des Linux-Kernels die Zwischenspeicherzuordnungen von Sequenzen nicht ordnungsgemäß, was zu einem Ganzzahlüberlauf, einem Schreibvorgang außerhalb des Bereichs und einer Eskalation zu root führt.
Durch CVE-2021-33910 hat systemd eine Speicherzuweisung mit einem übermäßigen Wert für die Größe (einschließlich strdupa und alloca für einen Pfadnamen, der von einem lokalen Angreifer gesteuert wird), was zu einem Betriebssystemabsturz führt.

Was soll ich tun?

Die Versionen von Linux- und COS-Knoten-Images für Anthos-Cluster auf VMware wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden Versionen:

  • 1.9
  • 1.8.2
  • 1.7.3
  • 1.6.4 (nur Linux)

Siehe Versionsverlauf – Kubernetes- und Knoten-Kernel-Versionen.

Hoch

GCP-2021-015

Veröffentlicht: 13.07.2021
Aktualisiert: 15.07.2021
Referenz: CVE-2021-22555

GKE

Beschreibung Schweregrad

Es wurde eine neue Sicherheitslücke (CVE-2021-22555) entdeckt, bei der ein böswilliger Akteur mit CAP_NET_ADMIN-Berechtigungen potenziell eine Container-Aufschlüsselung zum Root auf dem Host verursachen kann. Diese Sicherheitslücke betrifft alle GKE-Cluster und Anthos-Cluster auf VMware unter Linux-Version 2.6.19 oder höher.

Technische Details

Bei diesem Angriff kann ein ausgehender Schreibvorgang in setsockopt im Subsystem netfilter unter Linux zu einer Heap-Beschädigung (und damit Denial of Service) und einer Rechteausweitung führen.

Was soll ich tun?

Die folgenden Linux-Versionen in GKE wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden Versionen:

  • 1.21.1-gke.2200
  • 1.20.7-gke.2200
  • 1.19.11-gke.2100
  • 1.18.20-gke.501

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2021-22555

Hoch

Anthos-Cluster

Beschreibung Schweregrad

Es wurde eine neue Sicherheitslücke (CVE-2021-22555) entdeckt, bei der ein böswilliger Akteur mit CAP_NET_ADMIN-Berechtigungen potenziell eine Container-Aufschlüsselung zum Root auf dem Host verursachen kann. Diese Sicherheitslücke betrifft alle GKE-Cluster und Anthos-Cluster auf VMware unter Linux-Version 2.6.19 oder höher.

Technische Details

Bei diesem Angriff kann ein ausgehender Schreibvorgang in setsockopt im Subsystem netfilter unter Linux zu einer Heap-Beschädigung (und damit Denial of Service) und einer Rechteausweitung führen.

Was soll ich tun?

Die folgenden Versionen von Linux auf Anthos-Clustern in VMware wurden mit Code aktualisiert, um diese Sicherheitslücke zu schließen. Aktualisieren Sie Ihre Cluster auf eine der folgenden Versionen:

  • 1.8
  • 1.7.3
  • 1.6.4

Welche Sicherheitslücke wird mit diesem Patch behoben?

CVE-2021-22555

Hoch

GCP-2021-014

Veröffentlicht: 2021-07-05
Referenz: CVE-2021-34527

GKE

Beschreibung Schweregrad

Microsoft hat ein Sicherheitsbulletin CVE-2021-34527 zu einer Sicherheitslücke (Remote Code Execution, RCE) veröffentlicht, die Auswirkungen auf die Druckwarteschlange bei Windows-Servern hat. Das CERT Coordination Center (CERT/CC) hat einen Hinweis zu einer ähnlichen Sicherheitslücke mit dem Namen "PrintNightmare" veröffentlicht. Auch diese hat Auswirkungen auf Windows-Druckwarteschlangen – PrintNightmare, kritische Windows-Sicherheitslücke für Druckwarteschlange.

Was soll ich tun?

Sie müssen nichts unternehmen. GKE-Windows-Knoten enthalten den betroffenen Warteschlangendienst nicht im Basis-Image. GKE-Windows-Deployments sind daher von diesem Angriff nicht gefährdet.

Welche Sicherheitslücken werden mit diesem Bulletin behoben?

Hoch

GCP-2021-012

Veröffentlicht: 01.07.2021
Aktualisiert: 09.07.2021
Referenz: CVE-2021-34824

GKE

Beschreibung Schweregrad

Was soll ich tun?

Das Istio-Projekt hat kürzlich eine neue Sicherheitslücke offengelegt (CVE-2021-34824), die Istio betrifft. Istio weist eine Sicherheitslücke auf, die aus der Ferne ausgenutzt werden kann und bei der die in den Feldern "Gateway"und "DestinationRule credentialName" angegebenen Anmeldedaten über verschiedene Namespaces aufgerufen werden können.

Technische Details:

Das sichere Istio-Gateway oder die Arbeitslasten, die die DestinationRule verwenden, können private TLS-Schlüssel und Zertifikate aus Kubernetes-Secrets über die Konfiguration von credentialName laden. Ab Istio 1.8 werden die Secrets aus istiod gelesen und über XDS an Gateways und Arbeitslasten gesendet.

Normalerweise kann ein Gateway oder eine Arbeitslastbereitstellung nur auf TLS-Zertifikate und private Schlüssel zugreifen, die im Secret in seinem Namespace gespeichert sind. Aufgrund eines Programmfehlers in istiod kann ein Client, der auf die Istio XDS API zugreifen kann, jedoch alle TLS-Zertifikate und privaten Schlüssel abrufen, die in istiod im Cache gespeichert sind.

Was soll ich tun?

GKE-Cluster führen Istio nicht standardmäßig aus und verwenden, falls aktiviert, die Istio-Version 1.6, die für diesen Angriff nicht anfällig ist. Wenn Sie Istio im Cluster auf Istio 1.8 oder höher installiert oder darauf aktualisiert haben, führen Sie ein Upgrade auf Istio auf die neueste unterstützte Version durch.

Hoch

Anthos-Cluster

Beschreibung Schweregrad

Was soll ich tun?

Das Istio-Projekt hat kürzlich eine neue Sicherheitslücke offengelegt (CVE-2021-34824), die Istio betrifft. Istio weist eine Sicherheitslücke auf, die aus der Ferne ausgenutzt werden kann und bei der die in den Feldern "Gateway"und "DestinationRule credentialName" angegebenen Anmeldedaten über verschiedene Namespaces aufgerufen werden können.

Technische Details:

Das sichere Istio-Gateway oder die Arbeitslasten, die die DestinationRule verwenden, können private TLS-Schlüssel und Zertifikate aus Kubernetes-Secrets über die Konfiguration von credentialName laden. Ab Istio 1.8 werden die Secrets aus istiod gelesen und über XDS an Gateways und Arbeitslasten gesendet.

Normalerweise kann ein Gateway oder eine Arbeitslastbereitstellung nur auf TLS-Zertifikate und private Schlüssel zugreifen, die im Secret in seinem Namespace gespeichert sind. Aufgrund eines Programmfehlers in istiod kann ein Client, der auf die Istio XDS API zugreifen kann, jedoch alle TLS-Zertifikate und privaten Schlüssel abrufen, die in istiod im Cache gespeichert sind.

Was soll ich tun?

Anthos-Cluster auf VMware v1.6 und v1.7 sind von diesen Angriff nicht gefährdet. Anthos-Cluster auf VMware v1.8 sind dagegen bedroht.

Wenn Sie Anthos-Cluster unter VMware v1.8 verwenden, führen Sie ein Upgrade auf die folgende Patchversion oder höher durch:

  • 1.8.0-gke.25
Hoch

Anthos-Cluster

Beschreibung Schweregrad

Was soll ich tun?

Das Istio-Projekt hat kürzlich eine neue Sicherheitslücke offengelegt (CVE-2021-34824), die Istio betrifft. Istio weist eine Sicherheitslücke auf, die aus der Ferne ausgenutzt werden kann und bei der die in den Feldern "Gateway"und "DestinationRule credentialName" angegebenen Anmeldedaten über verschiedene Namespaces aufgerufen werden können.

Technische Details:

Das sichere Istio-Gateway oder die Arbeitslasten, die die DestinationRule verwenden, können private TLS-Schlüssel und Zertifikate aus Kubernetes-Secrets über die Konfiguration von credentialName laden. Ab Istio 1.8 werden die Secrets aus istiod gelesen und über XDS an Gateways und Arbeitslasten gesendet.

Normalerweise kann ein Gateway oder eine Arbeitslastbereitstellung nur auf TLS-Zertifikate und private Schlüssel zugreifen, die im Secret in seinem Namespace gespeichert sind. Aufgrund eines Programmfehlers in istiod kann ein Client, der auf die Istio XDS API zugreifen kann, jedoch alle TLS-Zertifikate und privaten Schlüssel abrufen, die in istiod im Cache gespeichert sind. Cluster, die mit Anthos-Cluster auf Bare Metal v1.8.0 erstellt oder aktualisiert wurden, sind von diesem CVE betroffen.

Was soll ich tun?

Die Anthos-Versionen 1.6 und 1.7 sind von diesem Angriff nicht gefährdet. Wenn Sie v1.8.0-Cluster haben, laden Sie die Version 1.8.1 von bmctl herunter, installieren Sie sie und aktualisieren Sie Ihre Cluster auf die folgende Patchversion:

  • 1.8.1
Hoch

GCP-2021-011

Veröffentlicht: 04.06.2021
Aktualisiert: 19.10.2021
Referenz: CVE-2021-30465

Aktualisierung vom 19.10.2021: Bulletins für Anthos-Cluster auf VMware, Anthos-Cluster in AWS und Anthos-Cluster auf Bare Metal hinzugefügt.

GKE

Beschreibung Schweregrad

Die Sicherheitscommunity hat kürzlich eine neue Sicherheitslücke (CVE-2021-30465) entdeckt, die in runc enthalten ist und möglicherweise einen vollständigen Zugriff auf ein Knotendateisystem ermöglicht.

Da für die Ausnutzung dieser Sicherheitslücke das Erstellen von Pods erforderlich ist, haben wir den Schweregrad dieser Sicherheitslücke mit MITTEL bewertet.

Technische Details

Das Paket runc ist bei der Bereitstellung eines Volumes anfällig für einen Symlink-Exchange-Angriff.

Bei diesem spezifischen Angriff kann ein Nutzer eine Race-Bedingung nutzen, indem er mehrere Pods gleichzeitig auf einem einzelnen Knoten startet. Diese Pods haben über einen Symlink dieselbe Volume-Bereitstellung.

Wenn der Angriff erfolgreich ist, stellt einer der Pods das Dateisystem des Knotens mit Root-Berechtigungen bereit.

Was soll ich tun?

Mit einem neu veröffentlichten Patch für runc (1.0.0-rc95) wird diese Sicherheitslücke behoben.

Führen Sie ein Upgrade Ihres GKE-Clusters auf eine der folgenden aktualisierten Versionen durch:

  • 1.18.19-gke.2100
  • 1.19.9-gke.1400
  • 1.20.6-gke.1400
  • 1.21.2-gke.600

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Die Sicherheitscommunity hat kürzlich eine neue Sicherheitslücke (CVE-2021-30465) entdeckt, die in runc enthalten ist und möglicherweise einen vollständigen Zugriff auf ein Knotendateisystem ermöglicht.

Da für die Ausnutzung dieser Sicherheitslücke bei Anthos-Cluster auf VMware das Erstellen von Pods erforderlich ist, haben wir den Schweregrad dieser Sicherheitslücke mit MITTEL bewertet.

Technische Details

Das Paket runc ist bei der Bereitstellung eines Volumes anfällig für einen Symlink-Exchange-Angriff.

Bei diesem spezifischen Angriff kann ein Nutzer eine Race-Bedingung nutzen, indem er mehrere Pods gleichzeitig auf einem einzelnen Knoten startet. Diese Pods haben über einen Symlink dieselbe Volume-Bereitstellung.

Wenn der Angriff erfolgreich ist, stellt einer der Pods das Dateisystem des Knotens mit Root-Berechtigungen bereit.

Was soll ich tun?

Mit einem neu veröffentlichten Patch für runc wird diese Sicherheitslücke behoben. Führen Sie ein Upgrade von Anthos-Cluster auf VMware auf eine der folgenden Versionen durch:

  • 1.7.3-gke-2
  • 1.8.1-gke.7
  • 1.9.0-gke.8

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Die Sicherheitscommunity hat kürzlich eine neue Sicherheitslücke (CVE-2021-30465) entdeckt, die in runc enthalten ist und möglicherweise einen vollständigen Zugriff auf ein Knotendateisystem ermöglicht.

Da es sich um eine Sicherheitslücke auf Betriebssystemebene handelt, ist Anthos-Cluster in AWS nicht anfällig.

Technische Details

Das Paket runc ist bei der Bereitstellung eines Volumes anfällig für einen Symlink-Exchange-Angriff.

Bei diesem spezifischen Angriff kann ein Nutzer eine Race-Bedingung nutzen, indem er mehrere Pods gleichzeitig auf einem einzelnen Knoten startet. Diese Pods haben über einen Symlink dieselbe Volume-Bereitstellung.

Wenn der Angriff erfolgreich ist, stellt einer der Pods das Dateisystem des Knotens mit Root-Berechtigungen bereit.

Was soll ich tun?

Achten Sie darauf, dass die Betriebssystemversion, auf der Sie Anthos-Cluster in AWS ausführen, auf die neueste Betriebssystemversion aktualisiert wird, die ein aktualisiertes runc-Paket hat.

Anthos-Cluster

Beschreibung Schweregrad

Die Sicherheitscommunity hat kürzlich eine neue Sicherheitslücke (CVE-2021-30465) entdeckt, die in runc enthalten ist und möglicherweise einen vollständigen Zugriff auf ein Knotendateisystem ermöglicht.

Da es sich um eine Sicherheitslücke auf Betriebssystemebene handelt, ist Anthos-Cluster auf Bare Metal nicht anfällig.

Technische Details

Das Paket runc ist bei der Bereitstellung eines Volumes anfällig für einen Symlink-Exchange-Angriff.

Bei diesem spezifischen Angriff kann ein Nutzer eine Race-Bedingung nutzen, indem er mehrere Pods gleichzeitig auf einem einzelnen Knoten startet. Diese Pods haben über einen Symlink dieselbe Volume-Bereitstellung.

Wenn der Angriff erfolgreich ist, stellt einer der Pods das Dateisystem des Knotens mit Root-Berechtigungen bereit.

Was soll ich tun?

Achten Sie darauf, dass die Betriebssystemversion, auf der Sie Anthos auf Bare Metal ausführen, auf die neueste Betriebssystemversion aktualisiert ist, die ein aktualisiertes runc-Paket hat.

GCP-2021-006

Veröffentlicht: 11.05.2021
Referenz: CVE-2021-31920

GKE

Beschreibung Schweregrad

Das Istio-Projekt legte kürzlich eine neue Sicherheitslücke offen (CVE-2021-31920), die Istio betrifft.

Istio enthält eine Sicherheitslücke, die aus der Ferne ausgenutzt werden kann und bei der eine HTTP-Anfrage mit mehreren Schrägstrichen oder mit maskierten Schrägstrichzeichen die Istio-Autorisierungsrichtlinie umgehen kann, wenn pfadbasierte Autorisierungsregeln verwendet werden.

Was soll ich tun?

Wir empfehlen dringend, GKE-Cluster zu aktualisieren und neu zu konfigurieren. Bitte führen Sie die beiden folgenden Schritte aus, um die Sicherheitslücke erfolgreich zu schließen:

  1. Cluster aktualisieren: Führen Sie so bald wie möglich die folgenden Schritte aus, um Ihre Cluster auf die neuesten Patchversionen zu aktualisieren:
    • Wenn Sie Istio in GKE 1.6 verwenden:

      Die neueste Patch-Version ist 1.6.14-gke.3. Folgen Sie der Upgrade-Anleitung, um Ihre Cluster auf die neueste Version zu aktualisieren.

    • Wenn Sie Istio in GKE 1.4 verwenden:
    • Istio on GKE 1.4-Releases werden von Istio nicht mehr unterstützt und CVE-Fehler werden nicht an diese Versionen zurückportiert. Folgen Sie den Anleitungen für das Istio-Upgrade, um Ihre Cluster auf 1.6 zu aktualisieren. Folgen Sie dann der obigen Anleitung, um die neueste Version von Istio in GKE 1.6 zu erhalten.

  2. Istio konfigurieren:

    Sobald Ihre Cluster gepatcht sind, müssen Sie Istio in GKE neu konfigurieren. Informationen zur richtigen Konfiguration Ihres Systems finden Sie im Leitfaden zu Best Practices für die Sicherheit.

Hoch

GCP-2021-004

Veröffentlicht: 06.05.2021
Referenz: CVE-2021-28683, CVE -2021-28682, CVE-2021-2958

GKE

Beschreibung Schweregrad

In den Envoy- und Istio-Projekten wurden kürzlich mehrere neue Sicherheitslücken offen gelegt (CVE-2021-28683, CVE-2021-28682). und CVE-2021-2958, die einem Angreifer ermöglichen könnten, Envoy abstürzen zu lassen.

GKE-Cluster führen Istio nicht standardmäßig aus und sind nicht anfällig. Wenn Istio in einem Cluster installiert und so konfiguriert ist, dass Dienste im Internet verfügbar sind, können diese Dienste anfällig für Denial-of-Service-Angriffe sein.

Was soll ich tun?

Aktualisieren Sie Ihre GKE-Steuerungsebene auf eine der folgenden Patchversionen, um diese Sicherheitslücken zu beheben:

  • 1.16.15-gke.16200
  • 1.17.17-gke.6100
  • 1.18.17-gke.1300
  • 1.19.9-gke.1300
  • 1.20.5-gke.1400
Mittel

Anthos-Cluster

Beschreibung Schweregrad

In den Envoy- und Istio-Projekten wurden kürzlich mehrere neue Sicherheitslücken offen gelegt (CVE-2021-28683, CVE-2021-28682). und CVE-2021-2958, die einem Angreifer ermöglichen könnten, Envoy abstürzen zu lassen.

Anthos-Cluster auf VMware verwenden standardmäßig Envoy für Ingress, sodass Ingress-Dienste anfällig für Denial of Service sind.

Was soll ich tun?

Aktualisieren Sie Anthos-Cluster auf VMware auf eine der folgenden Patchversionen, sobald diese veröffentlicht sind, um diese Sicherheitslücken zu beheben:

  • 1.5.4
  • 1.6.3
  • 1.7.1
Mittel

Anthos-Cluster

Aktualisiert: 06.05.2021

Beschreibung Schweregrad

In den Envoy- und Istio-Projekten wurden kürzlich mehrere neue Sicherheitslücken offen gelegt (CVE-2021-28683, CVE-2021-28682). und CVE-2021-2958, die einem Angreifer ermöglichen könnten, Envoy abstürzen zu lassen.

Da Anthos auf Bare-Metal standardmäßig Envoy für Ingress verwendet wird, sind Ingress-Dienste unter Umständen anfällig für Denial of Service.

Was soll ich tun?

Um diese Sicherheitslücken zu beheben, aktualisieren Sie Ihren Anthos in Bare Metal-Cluster auf eine der folgenden Patchversionen nach deren Veröffentlichung:

  • 1.6.3
  • 1.7.1
Mittel

GCP-2021-003

Veröffentlicht: 19.04.2021
Referenz: CVE-2021-25735

GKE

Beschreibung Schweregrad

Das Kubernetes-Projekt hat vor Kurzem eine neue Sicherheitslücke bekanntgegeben (CVE-2021-25735). Damit können Knoten-Updates einen validierenden Zulassungs-Webhook umgehen.

In einem Szenario, in dem ein Angreifer ausreichende Berechtigungen hat und in dem ein validierender Zulassungs-Webhook implementiert ist, der alte Node-Objektattribute wie z. B. Felder in Node.NodeSpec verwendet, kann der Angreifer Aktualisierungen von Attributen eines Knotens vornehmen. Dies führt eventuell zu einer Clustermanipulation. Keine der Richtlinien, die von GKE und von den integrierten Zulassungs-Controllern von Kubernetes erzwungen werden, sind davon betroffen. Wir empfehlen Kunden aber, alle zusätzlich installierten Zulassungs-Webhooks zu prüfen.

Was soll ich tun?

Um diese Sicherheitslücke zu beheben, aktualisieren Sie Ihren GKE-Cluster auf eine der folgenden Patchversionen:

  • 1.18.17-gke.900
  • 1.19.9-gke.900
  • 1.20.5-gke.900
Mittel

Anthos-Cluster

Beschreibung Schweregrad

Das Kubernetes-Projekt hat vor Kurzem eine neue Sicherheitslücke bekanntgegeben (CVE-2021-25735). Damit können Knoten-Updates einen validierenden Zulassungs-Webhook umgehen.

In einem Szenario, in dem ein Angreifer ausreichende Berechtigungen hat und in dem ein validierender Zulassungs-Webhook implementiert ist, der alte Node-Objektattribute wie z. B. Felder in Node.NodeSpec verwendet, kann der Angreifer Aktualisierungen von Attributen eines Knotens vornehmen. Dies führt eventuell zu einer Clustermanipulation. Keine der Richtlinien, die von GKE und von den integrierten Zulassungs-Controllern von Kubernetes erzwungen werden, sind davon betroffen. Wir empfehlen Kunden aber, alle zusätzlich installierten Zulassungs-Webhooks zu prüfen.

Was soll ich tun?

Diese Sicherheitslücke wird in einer der nächsten Patchversionen entschärft.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Das Kubernetes-Projekt hat vor Kurzem eine neue Sicherheitslücke bekanntgegeben (CVE-2021-25735). Damit können Knoten-Updates einen validierenden Zulassungs-Webhook umgehen.

In einem Szenario, in dem ein Angreifer ausreichende Berechtigungen hat und in dem ein validierender Zulassungs-Webhook implementiert ist, der alte Node-Objektattribute wie z. B. Felder in Node.NodeSpec verwendet, kann der Angreifer Aktualisierungen von Attributen eines Knotens vornehmen. Dies führt eventuell zu einer Clustermanipulation. Keine der Richtlinien, die von GKE und von den integrierten Zulassungs-Controllern von Kubernetes erzwungen werden, sind davon betroffen. Wir empfehlen Kunden aber, alle zusätzlich installierten Zulassungs-Webhooks zu prüfen.

Was soll ich tun?

Diese Sicherheitslücke wird in einer der nächsten Patchversionen entschärft.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Das Kubernetes-Projekt hat vor Kurzem eine neue Sicherheitslücke bekanntgegeben (CVE-2021-25735). Damit können Knoten-Updates einen validierenden Zulassungs-Webhook umgehen.

In einem Szenario, in dem ein Angreifer ausreichende Berechtigungen hat und in dem ein validierender Zulassungs-Webhook implementiert ist, der alte Node-Objektattribute wie z. B. Felder in Node.NodeSpec verwendet, kann der Angreifer Aktualisierungen von Attributen eines Knotens vornehmen. Dies führt eventuell zu einer Clustermanipulation. Keine der Richtlinien, die von GKE und von den integrierten Zulassungs-Controllern von Kubernetes erzwungen werden, sind davon betroffen. Wir empfehlen Kunden aber, alle zusätzlich installierten Zulassungs-Webhooks zu prüfen.

Was soll ich tun?

Diese Sicherheitslücke wird in einer der nächsten Patchversionen entschärft.

Mittel

GCP-2021-001

Veröffentlicht: 28.01.2021
Referenz: CVE-2021-3156

GKE

Beschreibung Schweregrad

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.

Google Kubernetes Engine-Cluster (GKE) sind von dieser Sicherheitslücke nicht betroffen:

  • Nutzer, die zum Herstellen einer SSH-Verbindung zu GKE-Knoten autorisiert sind, gelten bereits als stark privilegiert. Sie können mit sudo von Grund auf Root-Berechtigungen erhalten. Die Sicherheitslücke hat in diesem Szenario keine zusätzlichen Rechteausweitungspfade zur Folge.
  • Die meisten GKE-Systemcontainer basieren auf Distroless-Basis-Images, auf denen keine Shell und auch nicht sudo installiert ist. Andere Images werden aus einem Debian-Basis-Image erstellt, das kein sudo enthält. Selbst wenn sudo vorhanden war, gewähren Sie durch Zugriff auf sudo innerhalb des Containers keinen Zugriff auf den Host aufgrund der Containergrenze.

Was soll ich tun?

Da GKE-Cluster von dieser Sicherheitslücke nicht betroffen sind, sind keine weiteren Maßnahmen erforderlich.

GKE wird den Patch für diese Sicherheitslücke in die regelmäßigen künftigen Releases übernehmen.

Anthos-Cluster

Beschreibung Schweregrad

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.

Anthos-Cluster auf VMware sind von dieser Sicherheitslücke nicht betroffen:

  • Nutzer, die zum Herstellen einer SSH-Verbindung zu Anthos-Cluster auf VMware-Knoten autorisiert sind, gelten bereits als stark privilegiert. Sie können mit sudo Root-Berechtigungen anhand des Entwurfs erwerben. Die Sicherheitslücke hat in diesem Szenario keine zusätzlichen Rechteausweitungspfade zur Folge.
  • Die meisten Anthos-Cluster auf VMware-Systemcontainern werden aus distroless-Basis-Images erstellt, auf denen keine Shell oder sudo installiert ist. Andere Images werden aus einem Debian-Basis-Image erstellt, das kein sudo enthält. Selbst wenn sudo vorhanden war, gewähren Sie durch Zugriff auf sudo innerhalb des Containers keinen Zugriff auf den Host aufgrund der Containergrenze.

Was soll ich tun?

Da Anthos-Cluster auf VMware-Clustern von dieser Sicherheitslücke nicht betroffen sind, sind keine weiteren Maßnahmen erforderlich.

Anthos-Cluster auf VMware werden den Patch für diese Sicherheitslücke in regelmäßigen Releases anwenden.

Anthos-Cluster

Beschreibung Schweregrad

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.

Anthos-Cluster auf AWS sind von dieser Sicherheitslücke nicht betroffen:

  • Nutzer, die zum Herstellen einer SSH-Verbindung zu Anthos-Cluster auf AWS-Knoten autorisiert sind, gelten bereits als stark privilegiert. Sie können standardmäßig mit sudo Root-Berechtigungen erwerben. Die Sicherheitslücke hat in diesem Szenario keine zusätzlichen Rechteausweitungspfade zur Folge.
  • Die meisten Anthos-Cluster auf AWS-Systemcontainer werden aus Distroless-Basis-Images erstellt, bei denen keine Shell oder sudo installiert ist. Andere Images werden aus einem Debian-Basis-Image erstellt, das kein sudo enthält. Selbst wenn sudo vorhanden war, gewähren Sie durch Zugriff auf sudo innerhalb des Containers keinen Zugriff auf den Host aufgrund der Containergrenze.

Was soll ich tun?

Da Anthos-Cluster auf AWS-Clustern von dieser Sicherheitslücke nicht betroffen sind, sind keine weiteren Maßnahmen erforderlich.

Anthos-Cluster auf AWS werden den Patch für diese Sicherheitslücke regelmäßig in zukünftigen Releases anwenden.

Anthos-Cluster

Beschreibung Schweregrad

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.

Anthos in Bare-Metal-Clustern ist von dieser Sicherheitslücke nicht betroffen:

  • Nutzer, die für die SSH-Verbindung zu Anthos auf Bare-Metal-Knoten autorisiert sind, gelten bereits als stark privilegiert. Sie können über sudo Root-Berechtigungen erhalten. Die Sicherheitslücke hat in diesem Szenario keine zusätzlichen Rechteausweitungspfade zur Folge.
  • Die meisten Anthos-Systeme auf Bare-Metal-Systemen basieren auf Basis-Images, auf denen keine Shell oder sudo installiert ist. Andere Images werden aus einem Debian-Basis-Image erstellt, das kein sudo enthält. Selbst wenn sudo vorhanden war, gewähren Sie durch Zugriff auf sudo innerhalb des Containers keinen Zugriff auf den Host aufgrund der Containergrenze.

Was soll ich tun?

Da Anthos auf Bare-Metal-Clustern von dieser Sicherheitslücke nicht betroffen ist, sind keine weiteren Maßnahmen erforderlich.

Anthos auf Bare-Metal wird den Patch für diese Sicherheitslücke in regelmäßigen Releases anwenden.

GCP-2020-015

Veröffentlicht: 07.12.2020
Aktualisiert: 22.12.2021
Referenz: CVE-2020-8554

Aktualisierung vom 22.12.2021: Verwendet gcloud beta anstelle des Befehls gcloud.

Aktualisierung vom 15.12.2021: Zusätzliche Abhilfe für GKE.

GKE

Beschreibung Schweregrad
Aktualisiert am 22.12.2021: Der Befehl für GKE im folgenden Abschnitt sollte gcloud beta anstelle des Befehls gcloud verwenden.

gcloud beta container clusters update –no-enable-service-externalips

Aktualisiert am 15.12.2021: Für GKE ist jetzt die folgende Korrektur verfügbar:
  1. Ab GKE-Version 1.21 werden Dienste mit externen IP-Adressen von einem DenyServiceExternalIPs-Admission-Controller blockiert, der standardmäßig für neue Cluster aktiviert ist.
  2. Kunden, die ein Upgrade auf die GKE-Version 1.21 ausführen, können mit dem folgenden Befehl Dienste mit ExternalIPs blockieren:
    
    gcloud container clusters update –no-enable-service-externalips
    

Weitere Informationen finden Sie unter Clustersicherheit härten.


Das Kubernetes-Projekt hat eine neue Sicherheitslücke erkannt, CVE-2020-8554, durch die ein Angreifer, der Berechtigungen erhalten hat, einen Kubernetes-Dienst vom Typ LoadBalancer oder ClusterIP erstellen kann, um Netzwerktraffic von anderen Pods im Cluster abzufangen.

Diese Sicherheitslücke allein gibt einem Angreifer keine Berechtigung zum Erstellen eines Kubernetes-Dienstes.

Von dieser Sicherheitslücke sind alle GKE-Cluster (Google Kubernetes Engine) betroffen.

Was soll ich tun?

Möglicherweise muss Kubernetes in einer zukünftigen Version abwärts inkompatible Designänderungen vornehmen, um die Sicherheitslücke zu beheben.

Wenn viele Nutzer Zugriff auf Ihren Cluster mit Berechtigungen zum Erstellen von Diensten haben, z. B. in einem mehrmandantenfähigen Cluster, sollten Sie in der Zwischenzeit eine Risikominderung vornehmen. Der beste Ansatz zur Risikominderung besteht momentan darin, die Verwendung von ExternalIPs in einem Cluster einzuschränken. ExternalIPs sind keine häufig verwendete Funktion.

Schränken Sie die Verwendung von ExternalIPs in einem Cluster mit einer der folgenden Methoden ein:

  1. Verwenden Sie Anthos Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und wenden Sie sie an. Beispiele:
    
    # Only allow the creation of Services with no
    # ExternalIP or an ExternalIP of 203.0.113.1:
    
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sExternalIPs
    metadata:
      name: external-ips
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Service"]
      parameters:
        allowedIPs:
          - "203.0.113.1"
    
  2. Oder installieren Sie einen Admission-Controller, um die Verwendung von externen IP-Adressen zu verhindern. Das Kubernetes-Projekt hat einen Beispiel-Admission-Controller für diese Aufgabe bereitgestellt.

Wie in der Kubernetes-Ankündigung erwähnt, wird für Dienste vom Typ "LoadBalancer" keine Abhilfe geschaffen, da standardmäßig nur sehr privilegierte Nutzer und Systemkomponenten die container.services.updateStatus-Berechtigung haben, die zum Ausnutzen dieser Sicherheitslücke erforderlich ist.

Mittel

Anthos-Cluster

Beschreibung Schweregrad
Aktualisiert am 22.12.2021: Der Befehl für GKE im folgenden Abschnitt sollte gcloud beta anstelle des Befehls gcloud verwenden.

gcloud beta container clusters update –no-enable-service-externalips

Aktualisiert am 15.12.2021: Für GKE ist jetzt die folgende Korrektur verfügbar:
  1. Ab GKE-Version 1.21 werden Dienste mit externen IP-Adressen von einem DenyServiceExternalIPs-Admission-Controller blockiert, der standardmäßig für neue Cluster aktiviert ist.
  2. Kunden, die ein Upgrade auf die GKE-Version 1.21 ausführen, können mit dem folgenden Befehl Dienste mit ExternalIPs blockieren:
    
    gcloud container clusters update –no-enable-service-externalips
    

Weitere Informationen finden Sie unter Clustersicherheit härten.


Das Kubernetes-Projekt hat eine neue Sicherheitslücke erkannt, CVE-2020-8554, durch die ein Angreifer, der Berechtigungen erhalten hat, einen Kubernetes-Dienst vom Typ LoadBalancer oder ClusterIP erstellen kann, um Netzwerktraffic von anderen Pods im Cluster abzufangen.

Diese Sicherheitslücke allein gibt einem Angreifer keine Berechtigung zum Erstellen eines Kubernetes-Dienstes.

Von dieser Sicherheitslücke sind alle Anthos-Cluster auf VMware betroffen.

Was soll ich tun?

Möglicherweise muss Kubernetes in einer zukünftigen Version abwärts inkompatible Designänderungen vornehmen, um die Sicherheitslücke zu beheben.

Wenn viele Nutzer Zugriff auf Ihren Cluster mit Berechtigungen zum Erstellen von Diensten haben, z. B. in einem mehrmandantenfähigen Cluster, sollten Sie in der Zwischenzeit eine Risikominderung vornehmen. Der beste Ansatz zur Risikominderung besteht momentan darin, die Verwendung von ExternalIPs in einem Cluster einzuschränken. ExternalIPs sind keine häufig verwendete Funktion.

Schränken Sie die Verwendung von ExternalIPs in einem Cluster mit einer der folgenden Methoden ein:

  1. Verwenden Sie Anthos Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und wenden Sie sie an. Beispiele:
    
    # Only allow the creation of Services with no
    # ExternalIP or an ExternalIP of 203.0.113.1:
    
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sExternalIPs
    metadata:
      name: external-ips
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Service"]
      parameters:
        allowedIPs:
          - "203.0.113.1"
    
  2. Oder installieren Sie einen Admission-Controller, um die Verwendung von externen IP-Adressen zu verhindern. Das Kubernetes-Projekt hat einen Beispiel-Admission-Controller für diese Aufgabe bereitgestellt.

Wie in der Kubernetes-Ankündigung erwähnt, wird für Dienste vom Typ "LoadBalancer" keine Abhilfe geschaffen, da standardmäßig nur sehr privilegierte Nutzer und Systemkomponenten die container.services.updateStatus-Berechtigung haben, die zum Ausnutzen dieser Sicherheitslücke erforderlich ist.

Mittel

Anthos-Cluster

Beschreibung Schweregrad
Aktualisiert am 22.12.2021: Der Befehl für GKE im folgenden Abschnitt sollte gcloud beta anstelle des Befehls gcloud verwenden.

gcloud beta container clusters update –no-enable-service-externalips

Aktualisiert am 15.12.2021: Für GKE ist jetzt die folgende Korrektur verfügbar:
  1. Ab GKE-Version 1.21 werden Dienste mit externen IP-Adressen von einem DenyServiceExternalIPs-Admission-Controller blockiert, der standardmäßig für neue Cluster aktiviert ist.
  2. Kunden, die ein Upgrade auf die GKE-Version 1.21 ausführen, können mit dem folgenden Befehl Dienste mit ExternalIPs blockieren:
    
    gcloud container clusters update –no-enable-service-externalips
    

Weitere Informationen finden Sie unter Clustersicherheit härten.


Das Kubernetes-Projekt hat eine neue Sicherheitslücke erkannt, CVE-2020-8554, durch die ein Angreifer, der Berechtigungen erhalten hat, einen Kubernetes-Dienst vom Typ LoadBalancer oder ClusterIP erstellen kann, um Netzwerktraffic von anderen Pods im Cluster abzufangen.

Diese Sicherheitslücke allein gibt einem Angreifer keine Berechtigung zum Erstellen eines Kubernetes-Dienstes.

Von dieser Sicherheitslücke sind alle Anthos-Cluster auf AWS betroffen.

Was soll ich tun?

Möglicherweise muss Kubernetes in einer zukünftigen Version abwärts inkompatible Designänderungen vornehmen, um die Sicherheitslücke zu beheben.

Wenn viele Nutzer Zugriff auf Ihren Cluster mit Berechtigungen zum Erstellen von Diensten haben, z. B. in einem mehrmandantenfähigen Cluster, sollten Sie in der Zwischenzeit eine Risikominderung vornehmen. Der beste Ansatz zur Risikominderung besteht momentan darin, die Verwendung von ExternalIPs in einem Cluster einzuschränken. ExternalIPs sind keine häufig verwendete Funktion.

Schränken Sie die Verwendung von ExternalIPs in einem Cluster mit einer der folgenden Methoden ein:

  1. Verwenden Sie Anthos Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und wenden Sie sie an. Beispiele:
    
    # Only allow the creation of Services with no
    # ExternalIP or an ExternalIP of 203.0.113.1:
    
    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sExternalIPs
    metadata:
      name: external-ips
    spec:
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Service"]
      parameters:
        allowedIPs:
          - "203.0.113.1"
    
  2. Oder installieren Sie einen Admission-Controller, um die Verwendung von externen IP-Adressen zu verhindern. Das Kubernetes-Projekt hat einen Beispiel-Admission-Controller für diese Aufgabe bereitgestellt.

Wie in der Kubernetes-Ankündigung erwähnt, wird für Dienste vom Typ "LoadBalancer" keine Abhilfe geschaffen, da standardmäßig nur sehr privilegierte Nutzer und Systemkomponenten die container.services.updateStatus-Berechtigung haben, die zum Ausnutzen dieser Sicherheitslücke erforderlich ist.

Mittel

GCP-2020-014

Veröffentlicht: 20.10.2020
Referenz: CVE-2020-8563, CVE-2020-8564, CVE-2020-8565, CVE-2020-8566

GKE

Aktualisiert: 20.10.2020

Beschreibung Schweregrad

Beim Kubernetes-Projekt wurden unlängst mehrere Probleme entdeckt, durch die es zur Offenlegung von Secret-Daten kommen kann, wenn Optionen für das ausführliche Logging aktiviert sind. Die Probleme sind:

  • CVE-2020-8563: Schwachstellen bei Secrets in Logs für den kube-controller-manager des vSphere-Anbieters
  • CVE-2020-8564: Schwachstellen bei Docker-Konfigurations-Secrets, wenn die Datei fehlerhaft und loglevel >= 4 ist
  • CVE-2020-8565: Unvollständige Fehlerkorrektur für CVE-2019-11250 in Kubernetes ermöglicht Schwachstellen bei Tokens in Logs mit logLevel >= 9. Von GKE-Sicherheit erkannt.
  • CVE-2020-8566: Ceph RBD adminSecrets in Logs mit loglevel >= 4 offengelegt

GKE ist nicht betroffen.

Was soll ich tun?

Aufgrund der Standardebenen für das ausführliche Logging von GKE sind keine weiteren Maßnahmen erforderlich.

Anthos-Cluster

Updated: 10.10.2020

Beschreibung Schweregrad

Beim Kubernetes-Projekt wurden unlängst mehrere Probleme entdeckt, durch die es zur Offenlegung von Secret-Daten kommen kann, wenn Optionen für das ausführliche Logging aktiviert sind. Die Probleme sind:

  • CVE-2020-8563: Schwachstellen bei Secrets in Logs für den kube-controller-manager des vSphere-Anbieters
  • CVE-2020-8564: Schwachstellen bei Docker-Konfigurations-Secrets, wenn die Datei fehlerhaft und loglevel >= 4 ist
  • CVE-2020-8565: Unvollständige Fehlerkorrektur für CVE-2019-11250 in Kubernetes ermöglicht Schwachstellen bei Tokens in Logs mit logLevel >= 9. Von GKE-Sicherheit erkannt.
  • CVE-2020-8566: Ceph RBD adminSecrets in Logs mit loglevel >= 4 offengelegt

Anthos-Cluster auf VMware sind nicht betroffen.

Was soll ich tun?

Aufgrund der Standardebenen für das ausführliche Logging von GKE sind keine weiteren Maßnahmen erforderlich.

Anthos-Cluster

Aktualisiert: 20.10.2020

Beschreibung Schweregrad

Beim Kubernetes-Projekt wurden unlängst mehrere Probleme entdeckt, durch die es zur Offenlegung von Secret-Daten kommen kann, wenn Optionen für das ausführliche Logging aktiviert sind. Die Probleme sind:

  • CVE-2020-8563: Schwachstellen bei Secrets in Logs für den kube-controller-manager des vSphere-Anbieters
  • CVE-2020-8564: Schwachstellen bei Docker-Konfigurations-Secrets, wenn die Datei fehlerhaft und loglevel >= 4 ist
  • CVE-2020-8565: Unvollständige Fehlerkorrektur für CVE-2019-11250 in Kubernetes ermöglicht Schwachstellen bei Tokens in Logs mit logLevel >= 9. Von GKE-Sicherheit erkannt.
  • CVE-2020-8566: Ceph RBD adminSecrets in Logs mit loglevel >= 4 offengelegt

Anthos-Cluster auf AWS sind nicht betroffen.

Was soll ich tun?

Aufgrund der Standardebenen für das ausführliche Logging von GKE sind keine weiteren Maßnahmen erforderlich.

GCP-2020-012

Veröffentlicht: 14.09.2020
Referenz: CVE-2020-14386

GKE

Beschreibung Schweregrad

Im Linux-Kernel wurde eine Sicherheitslücke entdeckt, die unter CVE-2020-14386 beschrieben ist. Damit kann Container-Escape Root-Berechtigungen für den Hostknoten erhalten.

Alle GKE-Knoten sind betroffen. In GKE Sandbox ausgeführte Pods können diese Sicherheitslücke nicht nutzen.

Was soll ich tun?

Sie können als Gegenmaßnahme für diese Sicherheitslücke ein Upgrade Ihrer Steuerungsebene durchführen. Aktualisieren Sie dann Ihre Knoten auf eine der unten aufgelisteten Patchversionen.

  • 1.14.10-gke.50
  • 1.15.12-gke.20
  • 1.16.13-gke.401
  • 1.17.9-gke.1504
  • 1.18.6-gke.3504

e Ausnutzung dieser Sicherheitslücke erfordert CAP_NET_RAW, aber nur sehr wenige Container benötigen normalerweise CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig über PodSecurityPolicy oder den Policy Controller blockiert werden:

Entfernen Sie die Funktion CAP_NET_RAW mit einer der folgenden Methoden aus Containern:

  • Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • Oder durch Verwendung von Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • Durch Aktualisieren der Pod-Spezifikationen:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Abschwächung der folgenden Sicherheitslücke:

Die Sicherheitslücke CVE-2020-14386, über die Container mit CAP_NET_RAW 1 bis 10 Byte des Kernel-Arbeitsspeichers schreiben und den Container möglicherweise maskieren können, um Root-Berechtigungen auf dem Hostknoten zu erhalten. Der Schweregrad dieser Sicherheitslücke ist "Hoch".

Hoch

Anthos-Cluster

Aktualisiert: 17.09.2020

Beschreibung Schweregrad

Im Linux-Kernel wurde eine Sicherheitslücke entdeckt, die unter CVE-2020-14386 beschrieben ist. Damit kann Container-Escape Root-Berechtigungen für den Hostknoten erhalten.

Alle Anthos-Cluster auf VMware-Knoten sind betroffen.

Was soll ich tun?

Um diese Sicherheitslücke zu schließen, aktualisieren Sie Ihren Cluster auf eine Patchversion. Die Sicherheitslücken werden in den folgenden {gke_on_prem_name}}-Versionen behoben. Dieses Bulletin wird aktualisiert, sobald die Patchversionen verfügbar sind:

  • Anthos-Cluster auf VMware 1.4.3 sind jetzt verfügbar.
  • Anthos-Cluster auf VMware 1.3.4 jetzt verfügbar.

e Ausnutzung dieser Sicherheitslücke erfordert CAP_NET_RAW, aber nur sehr wenige Container benötigen normalerweise CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig über PodSecurityPolicy oder den Policy Controller blockiert werden:

Entfernen Sie die Funktion CAP_NET_RAW mit einer der folgenden Methoden aus Containern:

  • Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • Oder durch Verwendung von Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • Durch Aktualisieren der Pod-Spezifikationen:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Abschwächung der folgenden Sicherheitslücke:

Die Sicherheitslücke CVE-2020-14386, über die Container mit CAP_NET_RAW 1 bis 10 Byte des Kernel-Arbeitsspeichers schreiben und den Container möglicherweise maskieren können, um Root-Berechtigungen auf dem Hostknoten zu erhalten. Der Schweregrad dieser Sicherheitslücke ist "Hoch".

Hoch

Anthos-Cluster

Aktualisiert: 13.10.2020

Beschreibung Schweregrad

Im Linux-Kernel wurde eine Sicherheitslücke entdeckt, die unter CVE-2020-14386 beschrieben ist. Damit kann Container-Escape Root-Berechtigungen für den Hostknoten erhalten.

Alle Anthos-Cluster auf AWS-Knoten sind betroffen.

Was soll ich tun?

Um diese Sicherheitslücke zu schließen, aktualisieren Sie Ihren Verwaltungsdienst und Ihre Nutzercluster auf eine Patchversion. Bei den folgenden geplanten Anthos-Cluster auf AWS-Versionen oder bei neueren Versionen wird diese Sicherheitslücke geschlossen. Dieses Bulletin wird aktualisiert, sobald sie verfügbar sind:

  • 1.5.0-gke.6
  • 1.4.3-gke.7

Entfernen Sie die Funktion CAP_NET_RAW mit einer der folgenden Methoden aus Containern:

  • Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • Oder durch Verwendung von Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • Durch Aktualisieren der Pod-Spezifikationen:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Abschwächung der folgenden Sicherheitslücke:

Die Sicherheitslücke CVE-2020-14386, über die Container mit CAP_NET_RAW 1 bis 10 Byte des Kernel-Arbeitsspeichers schreiben und den Container möglicherweise maskieren können, um Root-Berechtigungen auf dem Hostknoten zu erhalten. Der Schweregrad dieser Sicherheitslücke ist "Hoch".

Hoch

GCP-2020-011

Veröffentlicht: 24.07.2020
Referenz: CVE-2020-8558

GKE

Beschreibung Schweregrad

Bei Kubernetes wurde vor Kurzem eine Sicherheitslücke im Netzwerk, CVE-2020-8558, entdeckt. Dienste kommunizieren manchmal über die lokale Loopback-Schnittstelle (127.0.0.1) mit anderen Anwendungen, die im gleichen Pod ausgeführt werden. Diese Sicherheitslücke ermöglicht einem Angreifer mit Zugriff auf das Netzwerk des Clusters, Traffic an die Loopback-Schnittstelle von angrenzenden Pods und Knoten zu senden. Dienste, die darauf angewiesen sind, dass die Loopback-Schnittstelle außerhalb ihres Pods nicht zugänglich ist, könnten ausgenutzt werden.

Damit ein Angreifer diese Sicherheitslücke in GKE-Clustern ausnutzen kann, muss er Netzwerkadministratorberechtigungen für die Google Cloud haben, in der die VPC des Clusters gehostet wird. Die Sicherheitslücke allein verleiht einem Angreifer keine Netzwerkadministratorberechtigungen. Aus diesem Grund wurde dieser Sicherheitslücke in GKE ein niedriger Schweregrad zugewiesen.

Was soll ich tun?

Führen Sie zum Beheben dieser Sicherheitslücke ein Upgrade für die Knotenpools Ihres Clusters auf die folgenden GKE-Versionen (oder höher) aus:

  • 1.17.7-gke.0
  • 1.16.11-gke.0
  • 1.16.10-gke.11
  • 1.16.9-gke.14

Welche Sicherheitslücke wird mit diesem Patch behoben?

Mit diesem Patch wird die folgende Sicherheitslücke behoben: CVE-2020-8558.

Niedrig

Anthos-Cluster

Beschreibung Schweregrad

Bei Kubernetes wurde vor Kurzem eine Sicherheitslücke im Netzwerk, CVE-2020-8558, entdeckt. Dienste kommunizieren manchmal über die lokale Loopback-Schnittstelle (127.0.0.1) mit anderen Anwendungen, die im gleichen Pod ausgeführt werden. Diese Sicherheitslücke ermöglicht einem Angreifer mit Zugriff auf das Netzwerk des Clusters, Traffic an die Loopback-Schnittstelle von angrenzenden Pods und Knoten zu senden. Dienste, die darauf angewiesen sind, dass die Loopback-Schnittstelle außerhalb ihres Pods nicht zugänglich ist, könnten ausgenutzt werden.

Was soll ich tun?

Aktualisieren Sie Ihren Cluster auf eine Patchversion, um diese Sicherheitslücke zu schließen. Die folgenden zukünftigen Anthos-Cluster auf VMware-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

  • Anthos-Cluster auf VMware 1.4.1

Welche Sicherheitslücke wird mit diesem Patch behoben?

Mit diesem Patch wird die folgende Sicherheitslücke behoben: CVE-2020-8558.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Bei Kubernetes wurde vor Kurzem eine Sicherheitslücke im Netzwerk, CVE-2020-8558, entdeckt. Dienste kommunizieren manchmal über die lokale Loopback-Schnittstelle (127.0.0.1) mit anderen Anwendungen, die im gleichen Pod ausgeführt werden. Diese Sicherheitslücke ermöglicht einem Angreifer mit Zugriff auf das Netzwerk des Clusters, Traffic an die Loopback-Schnittstelle von angrenzenden Pods und Knoten zu senden. Dienste, die darauf angewiesen sind, dass die Loopback-Schnittstelle außerhalb ihres Pods nicht zugänglich ist, könnten ausgenutzt werden.

Damit diese Sicherheitslücken in Nutzerclustern behoben werden können, muss ein Angreifer Quellzielprüfungen auf den EC2-Instanzen im Cluster deaktivieren. Dazu muss der Angreifer auf den EC2-Instanzen AWS-IAM-Berechtigungen für ModifyInstanceAttribute oder ModifyNetworkInterfaceAttribute haben. Aus diesem Grund wurde dieser Sicherheitslücke in Anthos-Cluster auf AWS ein niedriger Schweregrad zugewiesen.

Was soll ich tun?

Um diese Sicherheitslücke zu schließen, aktualisieren Sie Ihren Cluster auf eine Patchversion. Die Fehlerbehebung wird voraussichtlich von folgenden Anthos-Clustern auf AWS-Versionen oder höher ausgelöst:

  • Anthos-Cluster auf AWS 1.4.1-gke.17

Welche Sicherheitslücke wird mit diesem Patch behoben?

Mit diesem Patch wird die folgende Sicherheitslücke behoben: CVE-2020-8558.

Niedrig

GCP-2020-009

Veröffentlicht: 15.07.2020
Referenz: CVE-2020-8559

GKE

Beschreibung Schweregrad

Vor Kurzem wurde in Kubernetes eine Sicherheitslücke zur Rechteausweitung, CVE-2020-8559, entdeckt. Diese Sicherheitslücke ermöglicht es einem Angreifer, der bereits einen Knoten manipuliert hat, in jedem Pod im Cluster einen Befehl auszuführen. Der Angreifer kann dadurch mit dem bereits manipulierten Knoten andere Knoten manipulieren und potenziell Informationen lesen oder destruktive Aktionen ausführen.

Damit ein Angreifer diese Sicherheitslücke ausnutzen kann, muss bereits ein Knoten im Cluster manipuliert worden sein. Diese Sicherheitslücke allein lässt also nicht die Manipulation von Knoten in Ihrem Cluster zu.

Was soll ich tun?

Führen Sie ein Upgrade des Clusters auf eine Patchversion aus. Cluster werden in den nächsten Wochen automatisch aktualisiert und die Patchversionen werden bis zum 19. Juli 2020 verfügbar sein, um den Plan für ein manuelles Upgrade zu beschleunigen. Die folgenden (oder neueren) Versionen der GKE-Steuerungsebene enthalten die Fehlerkorrektur für diese Sicherheitslücke:

  • v1.14.10-gke.46
  • v1.15.12-gke.8
  • v1.16.9-gke.11
  • v1.16.10-gke.9
  • v1.16.11-gke.3+
  • v1.17.7-gke.6+

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8559. Diese Sicherheitslücke wird für GKE mit dem Schweregrad "Mittel" eingestuft, da der Angreifer Informationen aus erster Hand über den Cluster, die Knoten und Arbeitslasten benötigt, um diesen Angriff wirksam zu nutzen, und bereits ein anderer Knoten manipuliert worden sein muss. Diese Sicherheitslücke selbst bietet dem Angreifer keinen manipulierten Knoten.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Vor Kurzem wurde in Kubernetes eine Sicherheitslücke zur Rechteausweitung, CVE-2020-8559, entdeckt. Diese Sicherheitslücke ermöglicht es einem Angreifer, der bereits einen Knoten manipuliert hat, in jedem Pod im Cluster einen Befehl auszuführen. Der Angreifer kann dadurch mit dem bereits manipulierten Knoten andere Knoten manipulieren und potenziell Informationen lesen oder destruktive Aktionen ausführen.

Damit ein Angreifer diese Sicherheitslücke ausnutzen kann, muss bereits ein Knoten im Cluster manipuliert worden sein. Diese Sicherheitslücke allein lässt also nicht die Manipulation von Knoten in Ihrem Cluster zu.

Was soll ich tun?

Aktualisieren Sie Ihr Cluster auf eine Patchversion. Die folgenden zukünftigen Anthos-Cluster auf VMware-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

  • Anthos 1.3.3
  • Anthos 1.4.1

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8559. Diese Sicherheitslücke wird für GKE mit dem Schweregrad "Mittel" eingestuft, da der Angreifer Informationen aus erster Hand über den Cluster, die Knoten und Arbeitslasten benötigt, um diesen Angriff wirksam zu nutzen, und bereits ein anderer Knoten manipuliert worden sein muss. Diese Sicherheitslücke selbst bietet dem Angreifer keinen manipulierten Knoten.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Vor Kurzem wurde in Kubernetes eine Sicherheitslücke zur Rechteausweitung, CVE-2020-8559, entdeckt. Diese Sicherheitslücke ermöglicht es einem Angreifer, der bereits einen Knoten manipuliert hat, in jedem Pod im Cluster einen Befehl auszuführen. Der Angreifer kann dadurch mit dem bereits manipulierten Knoten andere Knoten manipulieren und potenziell Informationen lesen oder destruktive Aktionen ausführen.

Damit ein Angreifer diese Sicherheitslücke ausnutzen kann, muss bereits ein Knoten im Cluster manipuliert worden sein. Diese Sicherheitslücke allein lässt also nicht die Manipulation von Knoten in Ihrem Cluster zu.

Was soll ich tun?

Anthos-Cluster auf AWS GA (1.4.1, verfügbar ab Ende Juli 2020) oder höher enthält den Patch für diese Sicherheitslücke. Wenn Sie eine ältere Version verwenden, laden Sie eine neue Version des anthos-gke-Befehlszeilentools herunter und erstellen Sie Ihre Verwaltungs- und Nutzercluster neu.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8559. Diese Sicherheitslücke wird für GKE mit dem Schweregrad "Mittel" eingestuft, da der Angreifer Informationen aus erster Hand über den Cluster, die Knoten und Arbeitslasten benötigt, um diesen Angriff wirksam zu nutzen, und bereits ein anderer Knoten manipuliert worden sein muss. Diese Sicherheitslücke selbst bietet dem Angreifer keinen manipulierten Knoten.

Mittel

GCP-2020-007

Veröffentlicht: 01.06.2020
Referenz: CVE-2020-8555

GKE

Beschreibung Schweregrad

Serverseitige Anfragefälschung (Server Side Request Forgery, SSRF), CVE-2020-8555, wurde kürzlich in Kubernetes entdeckt und ermöglicht bestimmten autorisierten Nutzern, bis zu 500 Byte vertraulicher Informationen aus dem Hostnetzwerk der Steuerungsebene abzurufen. Die Google Kubernetes Engine-Steuerungsebene (GKE) verwendet Controller von Kubernetes und ist daher von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, die Steuerungsebene wie unten beschrieben auf die neueste Patchversion zu aktualisieren. Ein Knotenupgrade ist nicht erforderlich.

Was soll ich tun?

Bei den meisten Kunden sind keine weiteren Maßnahmen erforderlich. Die überwiegende Mehrheit der Cluster führt bereits eine Patchversion aus. Bei den folgenden GKE-Versionen sowie alle neueren Versionen wurde diese Sicherheitslücke behoben:
  • 1.14.7-gke.39
  • 1.14.8-gke.32
  • 1.14.9-gke.17
  • 1.14.10-gke.12
  • 1.15.7-gke.17
  • 1.16.4-gke.21
  • 1.17.0-gke.0

Cluster mit Release-Versionen verwenden bereits Versionen der Steuerungsebene mit Risikominderung.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8555. Diese Sicherheitslücke wird in GKE mit dem Schweregrad "Mittel" bewertet, da sie aufgrund verschiedener Härtungsmaßnahmen der Steuerungsebene nur schwer ausgenutzt werden konnte.

Ein Angreifer mit Berechtigungen zum Erstellen eines Pods mit bestimmten integrierten Volume-Typen (GlusterFS, Quobyte, StorageFS, ScaleIO) oder Berechtigungen zum Erstellen einer StorageClass kann kube-controller-manager dazu veranlassen, GET-Anfragen oder POST-Anfragen ohne von ihm kontrolliertem Anfragetext über das Master-Hostnetzwerk zu senden. Diese Volume-Typen werden selten auf GKE verwendet. Neue Nutzungsfälle dieser Volume-Typen können also ein hilfreiches Signal zur Angriffserkennung sein.

Wird der Angriff mit einer Methode kombiniert, um die Ergebnisse von GET/POST beispielsweise durch Logs zurück an den Angreifer zu senden, kann das zur Offenlegung von vertraulichen Informationen führen. Wir haben die entsprechenden Speichertreiber aktualisiert, um das Risiko von Schwachstellen zu beheben.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Serverseitige Anfragefälschung (Server Side Request Forgery, SSRF), CVE-2020-8555, wurde kürzlich in Kubernetes entdeckt und ermöglicht bestimmten autorisierten Nutzern, bis zu 500 Byte vertraulicher Informationen aus dem Hostnetzwerk der Steuerungsebene abzurufen. Die Google Kubernetes Engine-Steuerungsebene (GKE) verwendet Controller von Kubernetes und ist daher von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, die Steuerungsebene wie unten beschrieben auf die neueste Patchversion zu aktualisieren. Ein Knotenupgrade ist nicht erforderlich.

Was soll ich tun?

Die folgenden Anthos-Cluster auf VMware (GKE On-Prem)-Versionen oder höher enthalten die Fehlerkorrektur für diese Sicherheitslücke:

  • Anthos 1.3.0

Wenn Sie eine frühere Version verwenden, aktualisieren Sie Ihren vorhandenen Cluster auf eine Version, die diese Fehlerkorrektur enthält.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8555. Diese Sicherheitslücke wird in GKE mit dem Schweregrad "Mittel" bewertet, da sie aufgrund verschiedener Härtungsmaßnahmen der Steuerungsebene nur schwer ausgenutzt werden konnte.

Ein Angreifer mit Berechtigungen zum Erstellen eines Pods mit bestimmten integrierten Volume-Typen (GlusterFS, Quobyte, StorageFS, ScaleIO) oder Berechtigungen zum Erstellen einer StorageClass kann kube-controller-manager dazu veranlassen, GET-Anfragen oder POST-Anfragen ohne von ihm kontrolliertem Anfragetext über das Master-Hostnetzwerk zu senden. Diese Volume-Typen werden selten auf GKE verwendet. Neue Nutzungsfälle dieser Volume-Typen können also ein hilfreiches Signal zur Angriffserkennung sein.

Wird der Angriff mit einer Methode kombiniert, um die Ergebnisse von GET/POST beispielsweise durch Logs zurück an den Angreifer zu senden, kann das zur Offenlegung von vertraulichen Informationen führen. Wir haben die entsprechenden Speichertreiber aktualisiert, um das Risiko von Schwachstellen zu beheben.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Serverseitige Anfragefälschung (Server Side Request Forgery, SSRF), CVE-2020-8555, wurde kürzlich in Kubernetes entdeckt und ermöglicht bestimmten autorisierten Nutzern, bis zu 500 Byte vertraulicher Informationen aus dem Hostnetzwerk der Steuerungsebene abzurufen. Die Google Kubernetes Engine-Steuerungsebene (GKE) verwendet Controller von Kubernetes und ist daher von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, die Steuerungsebene wie unten beschrieben auf die neueste Patchversion zu aktualisieren. Ein Knotenupgrade ist nicht erforderlich.

Was soll ich tun?

Anthos-Cluster auf AWS (GKE on AWS) v0.2.0 oder höher enthält bereits den Patch für diese Sicherheitslücke. Wenn Sie eine ältere Version verwenden, laden Sie eine neue Version des anthos-gke-Befehlszeilentools herunter und erstellen Sie Ihre Verwaltungs- und Nutzercluster neu.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Diese Patches beheben die Sicherheitslücke CVE-2020-8555. Diese Sicherheitslücke wird in GKE mit dem Schweregrad "Mittel" bewertet, da sie aufgrund verschiedener Härtungsmaßnahmen der Steuerungsebene nur schwer ausgenutzt werden konnte.

Ein Angreifer mit Berechtigungen zum Erstellen eines Pods mit bestimmten integrierten Volume-Typen (GlusterFS, Quobyte, StorageFS, ScaleIO) oder Berechtigungen zum Erstellen einer StorageClass kann kube-controller-manager dazu veranlassen, GET-Anfragen oder POST-Anfragen ohne von ihm kontrolliertem Anfragetext über das Master-Hostnetzwerk zu senden. Diese Volume-Typen werden selten auf GKE verwendet. Neue Nutzungsfälle dieser Volume-Typen können also ein hilfreiches Signal zur Angriffserkennung sein.

Wird der Angriff mit einer Methode kombiniert, um die Ergebnisse von GET/POST beispielsweise durch Logs zurück an den Angreifer zu senden, kann das zur Offenlegung von vertraulichen Informationen führen. Wir haben die entsprechenden Speichertreiber aktualisiert, um das Risiko von Schwachstellen zu beheben.

Mittel

GCP-2020-006

Veröffentlicht: 01.06.2020
Referenz: Kubernetes-Problem 91507

GKE

Beschreibung Schweregrad

Kubernetes hat eine Sicherheitslücke entdeckt, die es einem berechtigten Container ermöglicht, Knoten-Traffic an einen anderen Container weiterzuleiten. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden. Alle GKE-Knoten (Google Kubernetes Engine) sind von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, ein Upgrade auf die neueste Patchversion auszuführen.

Was soll ich tun?

Sie können als Gegenmaßnahme für diese Sicherheitslücke ein Upgrade Ihrer Steuerungsebene durchführen. Aktualisieren Sie dann Ihre Knoten auf eine der unten aufgelisteten Patchversionen. Cluster mit Release-Versionen führen sowohl auf der Steuerungsebene als auch auf Knoten bereits Patchversionen aus:
  • 1.14.10-gke.36
  • 1.15.11-gke.15
  • 1.16.8-gke.15

Sehr wenige Container benötigen normalerweise CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig durch PodSecurityPolicy-Controller oder Anthos Policy Controller blockiert werden.

Entfernen Sie die Funktion CAP_NET_RAW mit einer der folgenden Methoden aus Containern:

  • Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • Oder durch Verwendung von Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • Durch Aktualisieren der Pod-Spezifikationen:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Entschärfung der folgenden Sicherheitslücke:

Die Sicherheitslücke, die unter Kubernetes-Problem 91507 beschrieben ist. Dabei kann die CAP_NET_RAW-Funktion (im standardmäßigen Container-Funktionsset enthalten) den IPv6-Stack auf dem Knoten schädlich konfigurieren und den Knoten-Traffic an den vom Angreifer kontrollierten Container weiterleiten. Dadurch kann der Angreifer ausgehenden und eingehenden Traffic des Knotens abfangen und ändern. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Kubernetes hat eine Sicherheitslücke entdeckt, die es einem berechtigten Container ermöglicht, Knoten-Traffic an einen anderen Container weiterzuleiten. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden. Alle GKE-Knoten (Google Kubernetes Engine) sind von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, ein Upgrade auf die neueste Patchversion auszuführen.

Was soll ich tun?

Führen Sie ein Upgrade Ihrer Cluster auf die folgende Version oder höher aus, um diese Sicherheitslücke für Anthos-Cluster auf VMware (GKE On-Prem) zu beheben:
  • Anthos 1.3.2

Normalerweise benötigen nur sehr wenige Container CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig über Anthos Policy Controller oder durch Aktualisieren Ihrer Pod-Spezifikationen blockiert werden:

Entfernen Sie die Funktion CAP_NET_RAW mit einer der folgenden Methoden aus Containern:

  • Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • Oder durch Verwendung von Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • Durch Aktualisieren der Pod-Spezifikationen:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Entschärfung der folgenden Sicherheitslücke:

Die Sicherheitslücke, die unter Kubernetes-Problem 91507 beschrieben ist. Dabei kann die CAP_NET_RAW-Funktion (im standardmäßigen Container-Funktionsset enthalten) den IPv6-Stack auf dem Knoten schädlich konfigurieren und den Knoten-Traffic an den vom Angreifer kontrollierten Container weiterleiten. Dadurch kann der Angreifer ausgehenden und eingehenden Traffic des Knotens abfangen und ändern. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden.

Mittel

Anthos-Cluster

Beschreibung Schweregrad

Kubernetes hat eine Sicherheitslücke entdeckt, die es einem berechtigten Container ermöglicht, Knoten-Traffic an einen anderen Container weiterzuleiten. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden. Alle GKE-Knoten (Google Kubernetes Engine) sind von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, ein Upgrade auf die neueste Patchversion auszuführen.

Was soll ich tun?

Laden Sie das anthos-gke-Befehlszeilentool herunter, das die folgende Version oder eine neuere Version enthält und erstellen Sie Ihre Verwaltungs- und Nutzercluster neu:

  • aws-0.2.1-gke.7

Sehr wenige Container benötigen normalerweise CAP_NET_RAW. Diese und andere leistungsstarke Funktionen sollten standardmäßig über Anthos Policy Controller oder durch Aktualisieren Ihrer Pod-Spezifikationen blockiert werden:

Entfernen Sie die Funktion CAP_NET_RAW mit einer der folgenden Methoden aus Containern:

  • Erzwingen Sie das Blockieren dieser Funktionen mit PodSecurityPolicy. Beispiel:
    
        # Require dropping CAP_NET_RAW with a PSP
        apiversion: extensions/v1beta1
        kind: PodSecurityPolicy
        metadata:
          name: no-cap-net-raw
        spec:
          requiredDropCapabilities:
            -NET_RAW
             ...
             # Unrelated fields omitted
  • Oder durch Verwendung von Policy Controller oder Gatekeeper mit dieser Einschränkungsvorlage und Anwendung der Vorlage. Beispiel:
    
        # Dropping CAP_NET_RAW with Gatekeeper
        # (requires the K8sPSPCapabilities template)
        apiversion: constraints.gatekeeper.sh/v1beta1
        kind:  K8sPSPCapabilities
        metadata:
          name: forbid-cap-net-raw
        spec:
          match:
            kinds:
              - apiGroups: [""]
              kinds: ["Pod"]
            namespaces:
              #List of namespaces to enforce this constraint on
              - default
            # If running gatekeeper >= v3.1.0-beta.5,
            # you can exclude namespaces rather than including them above.
            excludedNamespaces:
              - kube-system
          parameters:
            requiredDropCapabilities:
              - "NET_RAW"
  • Durch Aktualisieren der Pod-Spezifikationen:
    
        # Dropping CAP_NET_RAW from a Pod:
        apiVersion: v1
        kind: Pod
        metadata:
          name: no-cap-net-raw
        spec:
          containers:
            -name: my-container
             ...
            securityContext:
              capabilities:
                drop:
                  -NET_RAW

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Entschärfung der folgenden Sicherheitslücke:

Die Sicherheitslücke, die unter Kubernetes-Problem 91507 beschrieben ist. Dabei kann die CAP_NET_RAW-Funktion (im standardmäßigen Container-Funktionsset enthalten) den IPv6-Stack auf dem Knoten schädlich konfigurieren und den Knoten-Traffic an den vom Angreifer kontrollierten Container weiterleiten. Dadurch kann der Angreifer ausgehenden und eingehenden Traffic des Knotens abfangen und ändern. Gegenseitiger TLS/SSH-Traffic, z. B. zwischen dem Kubelet und dem API-Server oder Traffic von Anwendungen, die mTLS verwenden, kann durch diesen Angriff nicht gelesen oder geändert werden.

Mittel

GCP-2020-005

Veröffentlicht: 07.05.2020
Zuletzt aktualisiert: 07.05.2020
Referenz: CVE-2020-8835

GKE

Beschreibung Schweregrad

Vor Kurzem wurde im Linux-Kernel eine Sicherheitslücke entdeckt, die unter CVE-2020-8835 beschrieben wird. Sie ermöglicht Container-Escape, Root-Berechtigungen auf dem Hostknoten zu erhalten.

GKE-Ubuntu-Knoten (Google Kubernetes Engine) mit GKE 1.16 oder 1.17 sind von dieser Sicherheitslücke betroffen. Wir empfehlen Ihnen, so bald wie möglich wie unten beschrieben ein Upgrade auf die neueste Patchversion durchzuführen.

Knoten mit Container-Optimized OS sind nicht betroffen. Knoten, die auf Anthos-Clustern auf VMware ausgeführt werden, sind nicht betroffen.

Was soll ich tun?

Bei den meisten Kunden sind keine weiteren Maßnahmen erforderlich. Nur GKE-Ubuntu-Knoten mit GKE 1.16 oder 1.17 sind betroffen.

Führen Sie zuerst ein Upgrade auf die neueste Version für den Master durch. Dieser Patch ist in Kubernetes 1.16.8-gke.12, 1.17.4-gke.10 und neueren Releases verfügbar. Informationen zur Verfügbarkeit der Patches finden Sie in den Versionshinweisen.

Welche Sicherheitslücke wird mit diesem Patch behoben?

Dieser Patch dient zur Abschwächung der folgenden Sicherheitslücke:

In CVE-2020-8835 wird eine Sicherheitslücke in der Linux Kernel-Version 5.5.0 und neueren Versionen beschrieben, die es einem schädlichen Container mit minimaler Nutzerinteraktion in Form eines ausführbaren Befehls ermöglicht, Lese- und Schreibvorgänge im Kernel-Speicher durchzuführen und so auf dem Hostknoten Code auf Root-Ebene auszuführen. Der Schweregrad dieser Sicherheitslücke ist "Hoch".

Hoch

GCP-2020-004

Veröffentlicht: 07.05.2020
Aktualisiert: 20.05.2020
Referenz: CVE-2019-11254

Anthos-Cluster

Beschreibung Schweregrad

In Kubernetes wurde kürzlich eine in CVE-2019-11254 beschriebene Sicherheitslücke festgestellt. Sie erlaubt Nutzern, die POST-Anfragen stellen dürfen, DoS-Remoteangriffe auf Kubernetes API-Server. Das Kubernetes Product Security Committee (PSC) hat zusätzliche Informationen zu dieser Sicherheitslücke veröffentlicht.

Sie können diese Sicherheitslücke minimieren, indem Sie beschränken, welche Clients Netzwerkzugriff auf Ihre Kubernetes API-Server haben.

Was soll ich tun?

Wir empfehlen Ihnen, Ihre Cluster so bald wie möglich auf eine Patchversion zu aktualisieren, die diese Fehlerkorrektur enthält.

Die Patchversionen, mit denen die Sicherheitslücke behoben wird, sind unten aufgeführt:

  • Anthos 1.3.0, auf dem die Kubernetes-Version 1.15.7-gke.32 ausgeführt wird

Welche Sicherheitslücken werden mit diesem Patch behoben?

Mit dem Patch wird die folgende DoS-Sicherheitslücke (Denial of Service) behoben:

CVE-2019-11254

Mittel

GCP-2020-003

Veröffentlicht: 31.03.2020
Aktualisiert: 20.03.2020
Referenz: CVE-2019-11254

GKE

Beschreibung Schweregrad

In Kubernetes wurde kürzlich eine in CVE-2019-11254 beschriebene Sicherheitslücke festgestellt. Sie erlaubt Nutzern, die POST-Anfragen stellen dürfen, DoS-Remoteangriffe auf Kubernetes API-Server. Das Kubernetes Product Security Committee (PSC) hat zusätzliche Informationen zu dieser Sicherheitslücke veröffentlicht.

In GKE-Clustern, die autorisierte Masternetzwerke verwenden, und privaten Clustern ohne öffentlichen Endpunkt tritt diese Sicherheitslücke seltener auf.

Was soll ich tun?

Wir empfehlen ein Upgrade Ihres Clusters auf eine Patchversion, mit der diese Sicherheitslücke behoben wird.

Die Patchversionen, mit denen die Sicherheitslücke behoben wird, sind unten aufgeführt:

  • 1.13.12-gke.29
  • 1.14.9-gke.27
  • 1.14.10-gke.24
  • 1.15.9-gke.20
  • 1.16.6-gke.1

Welche Sicherheitslücken werden mit diesem Patch behoben?

Mit dem Patch wird die folgende DoS-Sicherheitslücke (Denial of Service) behoben:

CVE-2019-11254

Mittel

GCP-2020-002

Veröffentlicht: 23.03.2020
Zuletzt aktualisiert: 23.03.2020
Referenz: CVE-2020-8551, CVE-2020-8552

GKE

Beschreibung Schweregrad

Es wurden zwei DoS-Sicherheitslücken in Kubernetes offengelegt. Die eine betrifft den API-Server, die andere Kubelets. Weitere Einzelheiten finden Sie in den Kubernetes-Problemen 89377 und 89378.

Was soll ich tun?

GKE-Nutzer sind vor CVE-2020-8551 geschützt, sofern nur vertrauenswürdige Nutzer Anfragen innerhalb des internen Netzwerks des Clusters senden dürfen. Bei Verwendung autorisierter Masternetzwerke tritt CVE-2020-8552 außerdem seltener auf.

Wann gibt es einen Patch?

Patches für CVE-2020-8551 erfordern ein Upgrade des Knotens. Die Patchversionen, mit denen die Sicherheitslücke entschärft wird, sind unten aufgeführt:

  • 1.15.10-gke.*
  • 1.16.7-gke.*

Patches für CVE-2020-8552 erfordern ein Masterupgrade. Die Patchversionen, mit denen die Sicherheitslücke entschärft wird, sind unten aufgeführt:

  • 1.14.10-gke.32
  • 1.15.10-gke.*
  • 1.16.7-gke.*
Mittel

21. Januar 2020

Veröffentlicht: 20.01.2020
Aktualisiert: 24.01.2020
Referenz: CVE-2019-11254

GKE

Beschreibung Schweregrad

Aktualisierung vom 24. Januar 2020: Die Einführung von Patchversionen hat bereits begonnen und wird bis zum 25. Januar 2020 abgeschlossen.


Microsoft hat eine Sicherheitslücke in der Windows Crypto API und ihrer Validierung von Elliptische-Kurven-Signaturen offengelegt. Weitere Informationen finden Sie in der Offenlegung von Microsoft.

Was soll ich tun?

Bei den meisten Kunden sind keine weiteren Maßnahmen erforderlich. Es sind nur Knoten betroffen, die Windows Server ausführen.

Kunden, die Windows Server-Knoten verwenden, müssen sowohl die Knoten als auch die containerisierten Arbeitslasten, die auf diesen Knoten ausgeführt werden, auf gepatchte Versionen aktualisieren, um diese Sicherheitslücke zu verringern.

So aktualisieren Sie die Container:

Erstellen Sie Ihre Container mit den aktuellen Basis-Container-Images von Microsoft und wählen Sie dabei ein servercore- oder nanoserver-Tag mit LastUpdated-Zeit vom 14. Januar 2020 oder später aus.

So aktualisieren Sie die Knoten:

Die Einführung von Patchversionen hat bereits begonnen und wird bis zum 24. Januar 2020 abgeschlossen.

Sie können entweder bis zu diesem Zeitpunkt warten und ein Knotenupgrade für eine GKE-Patchversion vornehmen oder mit Windows Update jederzeit den aktuellen Windows-Patch manuell bereitstellen.

Die Sicherheitslücke wurde in folgenden Patchversionen entschärft:

  • 1.14.7-gke.40
  • 1.14.8-gke.33
  • 1.14.9-gke.23
  • 1.14.10-gke.17
  • 1.15.7-gke.23
  • 1.16.4-gke.22

Welche Sicherheitslücken werden mit diesem Patch behoben?

Dieser Patch dient zur Entschärfung der folgenden Sicherheitslücken:

CVE-2020-0601 – Diese Sicherheitslücke wird auch als Windows Crypto API-Spoofing-Sicherheitslücke bezeichnet. Sie 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 TLS-Nutzerverbindungen mit der betroffenen Software zu entschlüsseln.

NVD Base Score: 8,1 (hoch)

Archivierte Sicherheitsbulletins

Sicherheitsbulletins vor 2020 finden Sie im Sicherheitsbulletin-Archiv.