Bulletins de sécurité

Ce document décrit tous les bulletins de sécurité pour les produits suivants :

  • Google Kubernetes Engine (GKE)
  • Anthos clusters on VMware (GKE On-Prem)
  • Anthos clusters on AWS (GKE sur AWS)
  • Anthos clusters on bare metal

Les failles de sécurité sont souvent gardées secrètes jusqu'à ce que les parties concernées aient eu la possibilité de les corriger. Si tel est le cas, les notes de version de GKE font référence à des "mises à jour de sécurité" jusqu'à la levée du secret. Les notes sont alors mises à jour pour refléter les failles traitées par le correctif.

Pour en savoir plus sur la façon dont Google gère les failles de sécurité et les correctifs pour GKE et Anthos, consultez la page Correctifs de sécurité.

Utilisez ce flux XML pour vous abonner aux bulletins de sécurité de la présente page. S'abonner

GCP-2021-018

Date de publication : 2021-09-15
Référence : CVE-2021-25741

GKE

Description Gravité

Un problème de sécurité a été détecté dans Kubernetes, CVE-2021-25741, où un utilisateur peut créer un conteneur avec des montages de volume de sous-chemin pour accéder aux fichiers et répertoires en dehors du volume, y compris sur le système de fichiers hôte.

Détails techniques :

Dans la faille CVE-2021-25741, le pirate peut créer un lien symbolique d'un emptyDir installé au système de fichiers racine du nœud ( / ). Le kubelet suit le lien symbolique et installe la racine de l'hôte dans le conteneur.

Que dois-je faire ?

Les versions suivantes de Google Kubernetes Engine ont été mises à jour avec du code pour corriger cette faille. Mettez à niveau vos clusters vers l'une des versions suivantes :

  • v1.20.9-gke.701
  • v1.20.9-gke.1001
  • v1.20.8-gke.2101
  • v1.19.14-gke.301
  • v1.19.13-gke.701
  • v1.19.12-gke.2101
  • v1.18.20-gke.4501
  • v1.18.20-gke.3001
Élevé

Clusters Anthos sur

Description Gravité

Un problème de sécurité a été détecté dans Kubernetes, CVE-2021-25741, où un utilisateur peut créer un conteneur avec des montages de volume de sous-chemin pour accéder aux fichiers et répertoires en dehors du volume, y compris sur le système de fichiers hôte.

Détails techniques :

Dans la faille CVE-2021-25741, le pirate peut créer un lien symbolique d'un emptyDir installé au système de fichiers racine du nœud ( / ). Le kubelet suit le lien symbolique et installe la racine de l'hôte dans le conteneur.

Que dois-je faire ?

Les versions suivantes des clusters Anthos sur AWS ont été mises à jour avec du code pour corriger cette faille. Mettez à niveau vos clusters vers l'une des versions suivantes :

  • 1.8.2
Élevé

GCP-2021-017

Date de publication : 2021-09-01
Dernière mise à jour : 2021-09-15
Référence : CVE-2021-33909
CVE-2021-33910

GKE

Description Gravité

Mise à jour :

Les versions de GKE suivantes corrigent les failles :

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

Deux failles de sécurité, CVE-2021-33909 et CVE-2021-33910, ont été détectées dans le noyau Linux et ont provoqué un plantage du système d'exploitation ou une escalade par un utilisateur non privilégié à la racine. Cette faille affecte tous les systèmes d'exploitation de nœud GKE (COS et Ubuntu).

Détails techniques :

Dans la faille CVE-2021-33909, la couche du système de fichiers du noyau Linux ne limite pas correctement les allocations des tampons seq, ce qui conduit à un débordement d'entiers, à une écriture hors limite et à une escalade vers la racine.
Avec CVE-2021-33910, systemd dispose d'une allocation de mémoire avec une valeur de taille excessive (impliquant strdupa et alloca pour un nom de chemin d'accès contrôlé par un pirate informatique local) entraînant un plantage du système d'exploitation.

Que dois-je faire ?

Les versions des images de nœuds Linux pour les versions suivantes de GKE ont été mises à jour avec du code afin de corriger cette faille. Mettez à niveau vos clusters vers l'une des versions suivantes :

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

Clusters Anthos sur

Description Gravité

Deux failles de sécurité, CVE-2021-33909 et CVE-2021-33910, ont été détectées dans le noyau Linux et ont provoqué un plantage du système d'exploitation ou une escalade par un utilisateur non privilégié à la racine. Cette faille affecte tous les systèmes d'exploitation du nœud GKE (COS et Ubuntu).

Détails techniques :

Dans la faille CVE-2021-33909, la couche du système de fichiers du noyau Linux ne limite pas correctement les allocations des tampons seq, ce qui conduit à un débordement d'entiers, à une écriture hors limite et à une escalade vers la racine.
Avec CVE-2021-33910, systemd dispose d'une allocation de mémoire avec une valeur de taille excessive (impliquant strdupa et alloca pour un nom de chemin d'accès contrôlé par un pirate informatique local) entraînant un plantage du système d'exploitation.

Que dois-je faire ?

Les versions des images de nœuds Linux pour les clusters Anthos sur AWS ont été mises à jour avec du code afin de corriger cette faille. Mettez à niveau vos clusters vers l'une des versions suivantes :

  • 1.20.10-gke.600
  • 1.19.14-gke.600
  • 1.18.20-gke.4800
  • 1.17.17-gke.15800
Élevé

GCP-2021-015

Date de publication : 13-07-2021
Dernière mise à jour : 15-07-2021
Référence : CVE-2021-22555

GKE

Description Gravité

Une nouvelle faille de sécurité, CVE-2021-22555, a été détectée dans laquelle un acteur malveillant doté de privilèges CAP_NET_ADMIN peut permettre à l'interruption d'un conteneur de remonter jusqu'à l'accès racine de l'hôte. Cette faille affecte tous les clusters GKE et Anthos Clusters on VMware exécutant Linux 2.6.19 ou version ultérieure.

Détails techniques

Dans cette attaque, une écriture hors limite dans setsockopt dans le sous-système netfilter de Linux peut provoquer une corruption du tas de mémoire (et donc le déni de service) et une élévation des privilèges.

Que dois-je faire ?

Les versions suivantes de Linux sur GKE ont été mises à jour avec du code pour corriger cette faille. Mettez à niveau vos clusters vers l'une des versions suivantes :

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

Quelle faille ce correctif permet-il de résoudre ?

CVE-2021-22555

Élevé

Clusters Anthos sur

Description Gravité

Une nouvelle faille de sécurité, CVE-2021-22555, a été détectée dans laquelle un acteur malveillant doté de privilèges CAP_NET_ADMIN peut permettre à l'interruption d'un conteneur de remonter jusqu'à l'accès racine de l'hôte. Cette faille affecte tous les clusters GKE et Anthos Clusters on VMware exécutant Linux 2.6.19 ou version ultérieure.

Détails techniques

Dans cette attaque, une écriture hors limite dans setsockopt dans le sous-système netfilter de Linux peut provoquer une corruption du tas de mémoire (et donc le déni de service) et une élévation des privilèges.

Que dois-je faire ?

Les versions suivantes de Linux sur Anthos clusters on VMware ont été mises à jour avec du code pour corriger cette faille. Mettez à niveau vos clusters vers l'une des versions suivantes :

  • 1.8
  • 1.7.3
  • 1.6.4

Quelle faille ce correctif permet-il de résoudre ?

CVE-2021-22555

Élevé

GCP-2021-014

Date de publication : 2021-07-05
Référence: CVE-2021-34527

GKE

Description Gravité

Microsoft a publié un bulletin de sécurité sur la faille d'exécution de code à distance (RCE, Remote Code Execution) CVE-2021-34527, qui affecte le spouleur d'impression sur les serveurs Windows. Le CERT Coordination Center (CERT/CC) a publié une note de mise à jour sur une faille similaire, surnommée "PrintNightmare", qui affecte également les spouleurs d'impression Windows : PrintNightmare, Critical Windows Print Spooler Vulnerability.

Que dois-je faire ?

Aucune action n'est requise. Les nœuds Windows GKE ne contiennent pas le service de spouleur affecté dans l'image de base. Par conséquent, les déploiements Windows GKE ne sont pas vulnérables à cette attaque.

Quelles failles ce bulletin permet-il de résoudre ?

Élevé

GCP-2021-012

Date de publication : 01-07-2021
Dernière mise à jour : 09-07-2021
Référence : CVE-2021-34824

GKE

Description Gravité

Que dois-je faire ?

Le projet Istio a récemment divulgué une nouvelle faille de sécurité (CVE-2021-34824) affectant Istio. Istio souffre d'une faille utilisable à distance. Les identifiants spécifiés dans les champs Gateway et DestinationRule credentialName sont accessibles depuis différents espaces de noms.

Détails techniques :

La passerelle sécurisée Istio ou les charges de travail utilisant DestinationRule peuvent charger les clés privées et les certificats TLS à partir des secrets Kubernetes via la configuration de credentialName. À partir d'Istio 1.8 et versions ultérieures, les secrets sont lus à partir de istiod, et transmis aux passerelles et aux charges de travail via XDS.

Normalement, un déploiement de passerelle ou de charge de travail ne peut accéder qu'aux certificats TLS et aux clés privées stockées dans le secret au sein de son espace de noms. Cependant, un bug dans istiod permet à un client autorisé à accéder à l'API XDS Istio de récupérer tous les certificats TLS et clés privées mises en cache dans istiod.

Que dois-je faire ?

Les clusters GKE n'exécutent pas Istio par défaut et, lorsqu'ils sont activés, utilisent la version 1.6 d'Istio, qui n'est pas vulnérable à cette attaque. Si vous avez installé ou mis à niveau Istio sur le cluster vers Istio 1.8 ou une version ultérieure, mettez à niveau votre système vers la dernière version compatible.

Élevé

Clusters Anthos sur

Description Gravité

Que dois-je faire ?

Le projet Istio a récemment divulgué une nouvelle faille de sécurité (CVE-2021-34824) affectant Istio. Istio souffre d'une faille utilisable à distance. Les identifiants spécifiés dans les champs Gateway et DestinationRule credentialName sont accessibles depuis différents espaces de noms.

Détails techniques :

La passerelle sécurisée Istio ou les charges de travail utilisant DestinationRule peuvent charger les clés privées et les certificats TLS à partir des secrets Kubernetes via la configuration de credentialName. À partir d'Istio 1.8 et versions ultérieures, les secrets sont lus à partir de istiod, et transmis aux passerelles et aux charges de travail via XDS.

Normalement, un déploiement de passerelle ou de charge de travail ne peut accéder qu'aux certificats TLS et aux clés privées stockées dans le secret au sein de son espace de noms. Cependant, un bug dans istiod permet à un client autorisé à accéder à l'API XDS Istio de récupérer tous les certificats TLS et clés privées mises en cache dans istiod.

Que dois-je faire ?

Les clusters Anthos on VMware v1.6 et v1.7 ne sont pas vulnérables à cette attaque. Les clusters Anthos on VMware v1.8 sont vulnérables.

Si vous utilisez la version 1.8 d'Anthos Clusters on VMware, effectuez une mise à niveau vers la version corrigée suivante ou une version ultérieure :

  • 1.8.0-gke.25
Élevé

Clusters Anthos sur

Description Gravité

Que dois-je faire ?

Le projet Istio a récemment divulgué une nouvelle faille de sécurité (CVE-2021-34824) affectant Istio. Istio souffre d'une faille utilisable à distance. Les identifiants spécifiés dans les champs Gateway et DestinationRule credentialName sont accessibles depuis différents espaces de noms.

Détails techniques :

La passerelle sécurisée Istio ou les charges de travail utilisant DestinationRule peuvent charger les clés privées et les certificats TLS à partir des secrets Kubernetes via la configuration de credentialName. À partir d'Istio 1.8 et versions ultérieures, les secrets sont lus à partir de istiod, et transmis aux passerelles et aux charges de travail via XDS.

Normalement, un déploiement de passerelle ou de charge de travail ne peut accéder qu'aux certificats TLS et aux clés privées stockées dans le secret au sein de son espace de noms. Cependant, un bug dans istiod permet à un client autorisé à accéder à l'API XDS Istio de récupérer tous les certificats TLS et clés privées mises en cache dans istiod. Les clusters créés ou mis à niveau avec des clusters Anthos sur Bare Metal v1.8.0 sont affectés par cette faille CVE.

Que dois-je faire ?

Anthos v1.6 et 1.7 ne sont pas vulnérables à cette attaque. Si vous disposez de clusters v1.8.0, téléchargez et installez la version 1.8.1 de bmctl et mettez à niveau vos clusters vers la version corrigée suivante :

  • 1.8.1
Élevé

GCP-2021-011

Date de publication : 04-06-2021
Dernière mise à jour : 05-08-2021
Référence : CVE-2021-30465

GKE

Description Gravité

La communauté de sécurité a récemment divulgué une nouvelle faille de sécurité (CVE-2021-30465) dans runc est susceptible d'autoriser l'accès complet à un système de fichiers de nœud.

Pour GKE, étant donné que l'exploitation de cette faille nécessite la création de pods, nous avons évalué la gravité de cette faille sur MOYEN.

Détails techniques

Le package runc est vulnérable aux attaques par échange de liens symboliques lors de l'installation d'un volume.

Pour cette attaque spécifique, un utilisateur peut potentiellement exploiter une condition de concurrence en démarrant simultanément plusieurs pods sur un même nœud, qui partagent le même montage de volume avec un lien symbolique.

Si l'attaque aboutit, l'un des pods installe le système de fichiers du nœud avec des autorisations racine.

Que dois-je faire ?

Un nouveau correctif est disponible dans runc (1.0.0-rc95). Il permet de corriger cette faille.

Mettez à niveau votre cluster GKE vers l'une des versions mises à jour suivantes :

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

Moyen

GCP-2021-006

Date de publication : 11-05-2021
Référence : CVE-2021-31920

GKE

Description Gravité

Le projet Istio a récemment divulgué une nouvelle faille de sécurité (CVE-2021-31920) affectant Istio.

Istio souffre d'une faille utilisable à distance. Une requête HTTP comportant plusieurs barres obliques ou des barres obliques échappées peut contourner la règle d'autorisation Istio lorsque des règles d'autorisation basées sur le chemin sont utilisées.

Que dois-je faire ?

Nous vous recommandons vivement de mettre à jour et de reconfigurer vos clusters GKE. Notez que vous devez suivre les deux étapes ci-dessous pour résoudre le problème :

  1. Mettre à jour vos clusters : procédez comme suit pour mettre à jour vos clusters vers les versions les plus récentes dès que possible :
    • Si vous utilisez Istio sur GKE 1.6 :

      La dernière version du correctif est la 1.6.14-gke.3. Veuillez suivre les instructions de mise à niveau pour mettre à niveau vos clusters vers la dernière version.

    • Si vous utilisez Istio sur GKE 1.4 :
    • Les versions d'Istio sur GKE 1.4 ne sont plus compatibles avec Istio et nous ne rétroportons pas les correctifs CVE sur ces versions. Veuillez suivre les instructions de mise à niveau d'Istio pour mettre à niveau vos clusters vers la version 1.6, puis suivre les instructions ci-dessus pour obtenir la dernière version d'Istio sur GKE 1.6.

  2. Configurer Istio :

    Une fois le correctif appliqué aux clusters, vous devez reconfigurer Istio sur GKE. Reportez-vous au guide des bonnes pratiques de sécurité pour configurer correctement votre système.

Élevé

GCP-2021-004

Date de publication : 06-05-2021
Référence : CVE-2021-28683, CVE-2021-28682, CVE-2021-29258

GKE

Description Gravité

Les projets Envoy et Istio ont récemment divulgué plusieurs nouvelles failles de sécurité (CVE-2021-28683, CVE-2021-28682 et CVE-2021-29258), qui permettent à un pirate informatique de faire planter Envoy.

Les clusters GKE n'exécutent pas Istio par défaut et ne sont donc pas vulnérables. Si Istio a été installé dans un cluster et est configuré pour exposer des services sur Internet, ces services peuvent être vulnérables aux attaques par déni de service.

Que dois-je faire ?

Pour corriger ces failles, mettez à niveau le plan de contrôle GKE vers l'une des versions corrigées suivantes :

  • 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
Moyen

Clusters Anthos sur

Description Gravité

Les projets Envoy et Istio ont récemment divulgué plusieurs nouvelles failles de sécurité (CVE-2021-28683, CVE-2021-28682 et CVE-2021-29258), qui permettent à un pirate informatique de faire planter Envoy.

Anthos Clusters on VMware utilise Envoy par défaut pour l'objet Ingress. Par conséquent, les objets Ingress peuvent être vulnérables aux attaques par déni de service.

Que dois-je faire ?

Pour corriger ces failles, mettez à niveau Anthos Clusters on VMware vers l'une des versions corrigées suivantes lors de leur publication :

  • 1.5.4
  • 1.6.3
  • 1.7.1
Moyen

Clusters Anthos sur

Dernière mise à jour : 06-05-2021

Description Gravité

Les projets Envoy et Istio ont récemment divulgué plusieurs nouvelles failles de sécurité (CVE-2021-28683, CVE-2021-28682 et CVE-2021-29258), qui permettent à un pirate informatique de faire planter Envoy.

Anthos sur solution Bare Metal utilise par défaut Envoy pour l'objet Ingress, ce qui rend les services Ingress vulnérables aux attaques par déni de service.

Que dois-je faire ?

Pour corriger ces failles, mettez à niveau votre cluster Anthos sur solution Bare Metal vers l'une des versions corrigées suivantes lors de sa publication :

  • 1.6.3
  • 1.7.1
Moyen

GCP-2021-003

Date de publication : 19-04-2021
Référence : CVE-2021-25735

GKE

Description Gravité

Le projet Kubernetes a annoncé récemment une nouvelle faille de sécurité, CVE-2021-25735, qui pourrait permettre aux mises à jour de nœuds de contourner un webhook d'admission de validation.

Dans un scénario dans lequel un pirate informatique dispose de privilèges suffisants, et lorsqu'un webhook d'admission de validation est mis en œuvre à l'aide d'anciennes propriétés d'objet Node (par exemple, des champs dans Node.NodeSpec), le pirate a la possibilité de mettre à jour les propriétés d'un nœud, ce qui peut entraîner la compromission d'un cluster. Aucune des stratégies appliquées par GKE et les contrôleurs d'admission intégrés de Kubernetes n'est affectée, mais nous recommandons aux clients de vérifier les webhooks d'admission supplémentaires qu'ils ont installés, le cas échéant.

Que dois-je faire ?

Pour corriger cette faille, mettez à niveau votre cluster GKE vers l'une des versions corrigées suivantes :

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

Clusters Anthos sur

Description Gravité

Le projet Kubernetes a annoncé récemment une nouvelle faille de sécurité, CVE-2021-25735, qui pourrait permettre aux mises à jour de nœuds de contourner un webhook d'admission de validation.

Dans un scénario dans lequel un pirate informatique dispose de privilèges suffisants, et lorsqu'un webhook d'admission de validation est mis en œuvre à l'aide d'anciennes propriétés d'objet Node (par exemple, des champs dans Node.NodeSpec), le pirate a la possibilité de mettre à jour les propriétés d'un nœud, ce qui peut entraîner la compromission d'un cluster. Aucune des stratégies appliquées par GKE et les contrôleurs d'admission intégrés de Kubernetes n'est affectée, mais nous recommandons aux clients de vérifier les webhooks d'admission supplémentaires qu'ils ont installés, le cas échéant.

Que dois-je faire ?

Une prochaine version du correctif permettra de réduire les risques liés à cette faille.

Moyen

Clusters Anthos sur

Description Gravité

Le projet Kubernetes a annoncé récemment une nouvelle faille de sécurité, CVE-2021-25735, qui pourrait permettre aux mises à jour de nœuds de contourner un webhook d'admission de validation.

Dans un scénario dans lequel un pirate informatique dispose de privilèges suffisants, et lorsqu'un webhook d'admission de validation est mis en œuvre à l'aide d'anciennes propriétés d'objet Node (par exemple, des champs dans Node.NodeSpec), le pirate a la possibilité de mettre à jour les propriétés d'un nœud, ce qui peut entraîner la compromission d'un cluster. Aucune des stratégies appliquées par GKE et les contrôleurs d'admission intégrés de Kubernetes n'est affectée, mais nous recommandons aux clients de vérifier les webhooks d'admission supplémentaires qu'ils ont installés, le cas échéant.

Que dois-je faire ?

Une prochaine version du correctif permettra de réduire les risques liés à cette faille.

Moyen

Clusters Anthos sur

Description Gravité

Le projet Kubernetes a annoncé récemment une nouvelle faille de sécurité, CVE-2021-25735, qui pourrait permettre aux mises à jour de nœuds de contourner un webhook d'admission de validation.

Dans un scénario dans lequel un pirate informatique dispose de privilèges suffisants, et lorsqu'un webhook d'admission de validation est mis en œuvre à l'aide d'anciennes propriétés d'objet Node (par exemple, des champs dans Node.NodeSpec), le pirate a la possibilité de mettre à jour les propriétés d'un nœud, ce qui peut entraîner la compromission d'un cluster. Aucune des stratégies appliquées par GKE et les contrôleurs d'admission intégrés de Kubernetes n'est affectée, mais nous recommandons aux clients de vérifier les webhooks d'admission supplémentaires qu'ils ont installés, le cas échéant.

Que dois-je faire ?

Une prochaine version du correctif permettra de réduire les risques liés à cette faille.

Moyen

GCP-2021-001

Date de publication : 28-01-2021
Référence : CVE-2021-3156

GKE

Description Gravité

Une faille a été récemment découverte dans l'utilitaire Linux sudo. Cette faille, décrite dans CVE-2201-3156, peut permettre à un pirate informatique disposant d'un accès non privilégié à une interface système locale sur un système avec sudo installé de remonter jusqu'à l'accès racine du système.

Les clusters Google Kubernetes Engine (GKE) ne sont pas affectés par cette faille :

  • Les utilisateurs qui sont autorisés à se connecter en SSH à des nœuds GKE sont déjà considérés comme étant à privilèges élevés et peuvent déjà utiliser sudo pour obtenir les privilèges racine. La faille ne génère aucune élévation de privilèges supplémentaire dans ce scénario.
  • La plupart des conteneurs système GKE sont construits à partir d'images de base distroless sur lesquelles aucune interface système ou sudo n'est installée. D'autres images sont créées à partir d'une image de base debian qui ne contient pas sudo. Même si sudo est présent, l'accès à sudo à l'intérieur du conteneur ne vous permet pas d'accéder à l'hôte en raison de la limite du conteneur.

Que dois-je faire ?

Étant donné que les clusters GKE ne sont pas affectés par cette faille, aucune autre action n'est requise.

GKE disposera d'un correctif pour cette faille qui sera appliqué avec une version ultérieure dans le calendrier standard de mise à jour.

Aucun

Clusters Anthos sur

Description Gravité

Une faille a été récemment découverte dans l'utilitaire Linux sudo. Cette faille, décrite dans CVE-2201-3156, peut permettre à un pirate informatique disposant d'un accès non privilégié à une interface système locale sur un système avec sudo installé de remonter jusqu'à l'accès racine du système.

Anthos Clusters on VMware n'est pas affecté par cette faille :

  • Les utilisateurs qui sont autorisés à se connecter en SSH aux nœuds Anthos clusters on VMware sont déjà considérés comme étant à privilèges élevés, et peuvent utiliser sudo pour obtenir les privilèges racine par leur conception. La faille ne génère aucune élévation de privilèges supplémentaire dans ce scénario.
  • La plupart des conteneurs système Anthos clusters on VMware sont construits à partir d'images de base distroless sur lesquelles aucune interface système ou sudo n'est installée. D'autres images sont créées à partir d'une image de base debian qui ne contient pas sudo. Même si sudo est présent, l'accès à sudo à l'intérieur du conteneur ne vous permet pas d'accéder à l'hôte en raison de la limite du conteneur.

Que dois-je faire ?

Étant donné que cette faille n'a pas d'incidence sur Anthos Clusters on VMware, aucune autre action n'est requise.

Le correctif pour cette faille sera appliqué à Anthos Clusters on VMware avec une version ultérieure dans le calendrier standard de mise à jour.

Aucun

Clusters Anthos sur

Description Gravité

Une faille a été récemment découverte dans l'utilitaire Linux sudo. Cette faille, décrite dans CVE-2201-3156, peut permettre à un pirate informatique disposant d'un accès non privilégié à une interface système locale sur un système avec sudo installé de remonter jusqu'à l'accès racine du système.

Cette faille n'a pas d'incidence sur Anthos clusters on AWS :

  • Les utilisateurs qui sont autorisés à se connecter en SSH aux clusters Anthos sur AWS sont déjà considérés comme étant à privilèges élevés, et peuvent utiliser sudo pour obtenir les privilèges racine par leur conception. La faille ne génère aucune élévation de privilèges supplémentaire dans ce scénario.
  • La plupart des conteneurs associés à des clusters Anthos sur AWS sont construits à partir d'images de base distroless sur lesquelles aucune interface système ou sudo n'est installée. D'autres images sont créées à partir d'une image de base debian qui ne contient pas sudo. Même si sudo est présent, l'accès à sudo à l'intérieur du conteneur ne vous permet pas d'accéder à l'hôte en raison de la limite du conteneur.

Que dois-je faire ?

Étant donné que cette faille n'a pas d'incidence sur Anthos clusters on AWS, aucune autre action n'est requise.

Le correctif de cette faille sera appliqué à Anthos clusters on AWS avec une version ultérieure dans le calendrier standard de mise à jour.

Aucun

Clusters Anthos sur

Description Gravité

Une faille a été récemment découverte dans l'utilitaire Linux sudo. Cette faille, décrite dans CVE-2201-3156, peut permettre à un pirate informatique disposant d'un accès non privilégié à une interface système locale sur un système avec sudo installé de remonter jusqu'à l'accès racine du système.

Les clusters Anthos sur Bare Metal ne sont pas affectés par cette faille :

  • Les utilisateurs qui sont autorisés à se connecter en SSH à des nœuds Anthos sur solution Bare Metal sont déjà considérés comme étant à privilèges élevés. De ce fait, ils peuvent utiliser sudo pour obtenir des privilèges racine. La faille ne génère aucune élévation de privilèges supplémentaire dans ce scénario.
  • La plupart des conteneurs système Anthos sur solution Bare Metal sont créés à partir d'images de base distroless, qui ne contiennent aucune interface système, ni sudo. D'autres images sont créées à partir d'une image de base debian qui ne contient pas sudo. Même si sudo est présent, l'accès à sudo à l'intérieur du conteneur ne vous permet pas d'accéder à l'hôte en raison de la limite du conteneur.

Que dois-je faire ?

Étant donné que les clusters Anthos sur Bare Metal ne sont pas affectés par cette faille, aucune autre action n'est requise.

Le correctif de cette faille sera appliqué aux clusters Anthos sur Bare Metal avec une version ultérieure dans le calendrier standard de mise à jour.

Aucun

GCP-2020-015

Date de publication : 07-12-2020
Référence : CVE-2020-8554

GKE

Description Gravité

Le projet Kubernetes a récemment découvert une nouvelle faille de sécurité : CVE-2020-8554. Celle-ci peut permettre à un pirate informatique ayant obtenu les autorisations nécessaires pour créer un service Kubernetes de type LoadBalancer ou ClusterIP d'intercepter le trafic réseau provenant d'autres pods du cluster.

Cette faille, en elle-même, ne permet pas au pirate informatique de créer un service Kubernetes.

Tous les clusters Google Kubernetes Engine (GKE) sont affectés par cette faille.

Que dois-je faire ?

Kubernetes devra peut-être apporter des modifications d'incompatibilité ascendante dans une future version pour remédier à la faille.

Si de nombreux utilisateurs partagent l'accès à votre cluster avec les autorisations requises pour créer des services, par exemple dans un cluster mutualisé, envisagez d'appliquer une mesure d'atténuation. À l'heure actuelle, la meilleure approche pour l'atténuation consiste à limiter l'utilisation d'adresses IP externes dans un cluster. Les adresses IP externes ne sont pas une fonctionnalité couramment utilisée.

Limitez l'utilisation d'adresses IP externes dans un cluster avec l'une des méthodes suivantes :

  1. Utilisez Anthos Policy Controller ou GateKeeper avec ce modèle de contrainte et appliquez-le. Exemple :
    
    # 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. Vous pouvez également installer un contrôleur d'admission pour empêcher l'utilisation d'adresses IP externes. Le projet Kubernetes a fourni un exemple de contrôleur d'admission pour cette tâche.

Comme indiqué dans l'annonce concernant Kubernetes, aucune atténuation n'est fournie pour les services de type LoadBalancer, car par défaut, seuls les utilisateurs disposant des droits les plus privilégiés, ainsi que les composants du système, ont l'autorisation container.services.updateStatus nécessaire pour exploiter cette faille.

Moyen

Clusters Anthos sur

Description Gravité

Le projet Kubernetes a récemment découvert une nouvelle faille de sécurité : CVE-2020-8554. Celle-ci peut permettre à un pirate informatique ayant obtenu les autorisations nécessaires pour créer un service Kubernetes de type LoadBalancer ou ClusterIP d'intercepter le trafic réseau provenant d'autres pods du cluster.

Cette faille, en elle-même, ne permet pas au pirate informatique de créer un service Kubernetes.

Tous les clusters Anthos Clusters on VMware sont affectés par cette faille.

Que dois-je faire ?

Kubernetes devra peut-être apporter des modifications d'incompatibilité ascendante dans une future version pour remédier à la faille.

Si de nombreux utilisateurs partagent l'accès à votre cluster avec les autorisations requises pour créer des services, par exemple dans un cluster mutualisé, envisagez d'appliquer une mesure d'atténuation. À l'heure actuelle, la meilleure approche pour l'atténuation consiste à limiter l'utilisation d'adresses IP externes dans un cluster. Les adresses IP externes ne sont pas une fonctionnalité couramment utilisée.

Limitez l'utilisation d'adresses IP externes dans un cluster avec l'une des méthodes suivantes :

  1. Utilisez Anthos Policy Controller ou GateKeeper avec ce modèle de contrainte et appliquez-le. Exemple :
    
    # 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. Vous pouvez également installer un contrôleur d'admission pour empêcher l'utilisation d'adresses IP externes. Le projet Kubernetes a fourni un exemple de contrôleur d'admission pour cette tâche.

Comme indiqué dans l'annonce concernant Kubernetes, aucune atténuation n'est fournie pour les services de type LoadBalancer, car par défaut, seuls les utilisateurs disposant des droits les plus privilégiés, ainsi que les composants du système, ont l'autorisation container.services.updateStatus nécessaire pour exploiter cette faille.

Moyen

Clusters Anthos sur

Description Gravité

Le projet Kubernetes a récemment découvert une nouvelle faille de sécurité : CVE-2020-8554. Celle-ci peut permettre à un pirate informatique ayant obtenu les autorisations nécessaires pour créer un service Kubernetes de type LoadBalancer ou ClusterIP d'intercepter le trafic réseau provenant d'autres pods du cluster.

Cette faille, en elle-même, ne permet pas au pirate informatique de créer un service Kubernetes.

Tous les clusters Anthos clusters on AWS sont affectés par cette faille.

Que dois-je faire ?

Kubernetes devra peut-être apporter des modifications d'incompatibilité ascendante dans une future version pour remédier à la faille.

Si de nombreux utilisateurs partagent l'accès à votre cluster avec les autorisations requises pour créer des services, par exemple dans un cluster mutualisé, envisagez d'appliquer une mesure d'atténuation. À l'heure actuelle, la meilleure approche pour l'atténuation consiste à limiter l'utilisation d'adresses IP externes dans un cluster. Les adresses IP externes ne sont pas une fonctionnalité couramment utilisée.

Limitez l'utilisation d'adresses IP externes dans un cluster avec l'une des méthodes suivantes :

  1. Utilisez Anthos Policy Controller ou GateKeeper avec ce modèle de contrainte et appliquez-le. Exemple :
    
    # 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. Vous pouvez également installer un contrôleur d'admission pour empêcher l'utilisation d'adresses IP externes. Le projet Kubernetes a fourni un exemple de contrôleur d'admission pour cette tâche.

Comme indiqué dans l'annonce concernant Kubernetes, aucune atténuation n'est fournie pour les services de type LoadBalancer, car par défaut, seuls les utilisateurs disposant des droits les plus privilégiés, ainsi que les composants du système, ont l'autorisation container.services.updateStatus nécessaire pour exploiter cette faille.

Moyen

GCP-2020-014

Date de publication : 20-10-2020
Référence : CVE-2020-8563, CVE-2020-8564, CVE-2020-8565, CVE-2020-8566

GKE

Dernière mise à jour : 20-10-2020

Description Gravité

Le projet Kubernetes a récemment découvert plusieurs problèmes qui permettent l'exposition des données des secrets lors de l'activation des options de journalisation détaillée. Les problèmes sont les suivants :

  • CVE-2020-8563 : fuites des secrets dans les journaux du fournisseur vSphere kube-controller-manager
  • CVE-2020-8564 : fuite des secrets de configuration Docker lorsque le fichier est mal formé, et que le niveau de journalisation est supérieur ou égal à 4.
  • CVE-2020-8565 : correction partielle de la faille CVE-2019-11250 dans Kubernetes occasionnant la divulgation des jetons dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 9. Faille détectée par la sécurité de GKE.
  • CVE-2020-8566 : fuite des secrets des administrateurs Ceph RBD dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 4.

GKE n'est pas affecté.

Que dois-je faire ?

Aucune autre action n'est requise en raison des niveaux de journalisation détaillée par défaut de GKE.

Aucun

Clusters Anthos sur

Mise à jour : 10-10-2020

Description Gravité

Le projet Kubernetes a récemment découvert plusieurs problèmes qui permettent l'exposition des données des secrets lors de l'activation des options de journalisation détaillée. Les problèmes sont les suivants :

  • CVE-2020-8563 : fuites des secrets dans les journaux du fournisseur vSphere kube-controller-manager
  • CVE-2020-8564 : fuite des secrets de configuration Docker lorsque le fichier est mal formé, et que le niveau de journalisation est supérieur ou égal à 4.
  • CVE-2020-8565 : correction partielle de la faille CVE-2019-11250 dans Kubernetes occasionnant la divulgation des jetons dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 9. Faille détectée par la sécurité de GKE.
  • CVE-2020-8566 : fuite des secrets des administrateurs Ceph RBD dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 4.

Anthos Clusters on VMware n'est pas affecté.

Que dois-je faire ?

Aucune autre action n'est requise en raison des niveaux de journalisation détaillée par défaut de GKE.

Aucun

Clusters Anthos sur

Dernière mise à jour : 20-10-2020

Description Gravité

Le projet Kubernetes a récemment découvert plusieurs problèmes qui permettent l'exposition des données des secrets lors de l'activation des options de journalisation détaillée. Les problèmes sont les suivants :

  • CVE-2020-8563 : fuites des secrets dans les journaux du fournisseur vSphere kube-controller-manager
  • CVE-2020-8564 : fuite des secrets de configuration Docker lorsque le fichier est mal formé, et que le niveau de journalisation est supérieur ou égal à 4.
  • CVE-2020-8565 : correction partielle de la faille CVE-2019-11250 dans Kubernetes occasionnant la divulgation des jetons dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 9. Faille détectée par la sécurité de GKE.
  • CVE-2020-8566 : fuite des secrets des administrateurs Ceph RBD dans les journaux lorsque le niveau de journalisation est supérieur ou égal à 4.

Les clusters Anthos clusters on AWS ne sont pas affectés.

Que dois-je faire ?

Aucune autre action n'est requise en raison des niveaux de journalisation détaillée par défaut de GKE.

Aucun

GCP-2020-012

Date de publication : 14-09-2020
Référence : CVE-2020-14386

GKE

Description Gravité

Une faille a été récemment découverte dans le noyau Linux, décrite dans CVE-2020-14386, qui permet de s'échapper d'un conteneur pour obtenir un accès root sur le nœud hôte.

Tous les nœuds GKE sont affectés. Les pods exécutés dans GKE Sandbox ne peuvent pas exploiter cette faille.

Que dois-je faire ?

Pour corriger cette faille, mettez à jour le plan de contrôle, puis les nœuds vers l'une des versions corrigées répertoriées ci-dessous :

  • 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

L'exploitation de cette faille nécessite CAP_NET_RAW, mais très peu de conteneurs utilisent CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via PodSecurityPolicy ou Policy Controller :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
        # 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
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
        # 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"
  • Ou en mettant à jour les spécifications du pod :
    
        # 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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille CVE-2020-14386 permet aux conteneurs avec CAP_NET_RAW d'écrire de 1 à 10 octets de mémoire du noyau, ce qui peut permettre à un pirate de sortir du conteneur et d'obtenir des privilèges racine sur le nœud hôte. La gravité de cette faille est évaluée comme élevée.

Élevé

Clusters Anthos sur

Mise à jour : 17-09-2020

Description Gravité

Une faille a été récemment découverte dans le noyau Linux, décrite dans CVE-2020-14386, qui permet de s'échapper d'un conteneur pour obtenir un accès root sur le nœud hôte.

Tous les nœuds Anthos clusters on VMware sont concernés.

Que dois-je faire ?

Pour résoudre cette faille, mettez à niveau votre cluster vers une version incluant le correctif. Les prochaines versions de {gke_on_prem_name}} incluront le correctif pour cette faille. Le présent bulletin sera mis à jour dès que le correctif sera disponible :

  • Anthos clusters on VMware 1.4.3 est désormais disponible.
  • Anthos clusters on VMware 1.3.4 est désormais disponibles.

L'exploitation de cette faille nécessite CAP_NET_RAW, mais très peu de conteneurs utilisent CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via PodSecurityPolicy ou Policy Controller :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
        # 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
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
        # 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"
  • Ou en mettant à jour les spécifications du pod :
    
        # 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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille CVE-2020-14386 permet aux conteneurs avec CAP_NET_RAW d'écrire de 1 à 10 octets de mémoire du noyau, ce qui peut permettre à un pirate de sortir du conteneur et d'obtenir des privilèges racine sur le nœud hôte. La gravité de cette faille est évaluée comme élevée.

Élevé

Clusters Anthos sur

Dernière mise à jour : 13-10-2020

Description Gravité

Une faille a été récemment découverte dans le noyau Linux, décrite dans CVE-2020-14386, qui permet de s'échapper d'un conteneur pour obtenir un accès root sur le nœud hôte.

Tous les nœuds Anthos clusters sur AWS sont affectés.

Que dois-je faire ?

Pour corriger cette faille, mettez à niveau votre service de gestion et vos clusters d'utilisateur vers une version corrigée. Les versions à venir suivantes de Anthos clusters sur AWS ou les versions ultérieures incluront le correctif pour cette faille, et ce bulletin sera mis à jour dès qu'elles seront disponibles :

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

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
        # 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
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
        # 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"
  • Ou en mettant à jour les spécifications du pod :
    
        # 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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille CVE-2020-14386 permet aux conteneurs avec CAP_NET_RAW d'écrire de 1 à 10 octets de mémoire du noyau, ce qui peut permettre à un pirate de sortir du conteneur et d'obtenir des privilèges racine sur le nœud hôte. La gravité de cette faille est évaluée comme élevée.

Élevé

GCP-2020-011

Date de publication : 24-07-2020
Référence : CVE-2020-8558

GKE

Description Gravité

Une faille réseau, CVE-2020-8558, a été récemment détectée dans Kubernetes. Les services communiquent parfois avec d'autres applications s'exécutant dans le même pod à l'aide de l'interface de rebouclage local (127.0.0.1). Cette faille permet à un pirate informatique ayant accès au réseau du cluster d'envoyer du trafic à l'interface de rebouclage des pods et nœuds adjacents. Les services reposant sur l'interface de rebouclage et non accessibles en dehors de leur pod peuvent être exploités.

Pour exploiter cette faille sur les clusters GKE, le pirate informatique doit disposer de droits d'administrateur réseau sur le service Google Cloud hébergeant le VPC du cluster. Cette faille seule n'accorde pas de droits d'administrateur réseau au pirate informatique. Pour cette raison, le niveau de gravité de cette faille est faible pour GKE.

Que dois-je faire ?

Pour corriger cette faille, mettez à jour les pools de nœuds de votre cluster vers les versions GKE suivantes (ou ultérieures) :

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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif résout la faille suivante : CVE-2020-8558.

Faible

Clusters Anthos sur

Description Gravité

Une faille réseau, CVE-2020-8558, a été récemment détectée dans Kubernetes. Les services communiquent parfois avec d'autres applications s'exécutant dans le même pod à l'aide de l'interface de rebouclage local (127.0.0.1). Cette faille permet à un pirate informatique ayant accès au réseau du cluster d'envoyer du trafic à l'interface de rebouclage des pods et nœuds adjacents. Les services reposant sur l'interface de rebouclage et non accessibles en dehors de leur pod peuvent être exploités.

Que dois-je faire ?

Pour résoudre cette faille, mettez à niveau votre cluster vers une version incluant le correctif. Les versions ultérieures de Anthos clusters on VMware incluront le correctif pour cette faille :

  • Anthos clusters on VMware 1.4.1

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif résout la faille suivante : CVE-2020-8558.

Moyen

Clusters Anthos sur

Description Gravité

Une faille réseau, CVE-2020-8558, a été récemment détectée dans Kubernetes. Les services communiquent parfois avec d'autres applications s'exécutant dans le même pod à l'aide de l'interface de rebouclage local (127.0.0.1). Cette faille permet à un pirate informatique ayant accès au réseau du cluster d'envoyer du trafic à l'interface de rebouclage des pods et nœuds adjacents. Les services reposant sur l'interface de rebouclage et non accessibles en dehors de leur pod peuvent être exploités.

Pour exploiter cette faille sur les clusters d'utilisateur, un pirate informatique doit désactiver les vérifications source/destination sur les instances EC2 du cluster. Pour ce faire, le pirate informatique doit disposer des autorisations AWS IAM pour ModifyInstanceAttribute ou ModifyNetworkInterfaceAttribute sur les instances EC2. Par conséquent, la gravité de cette faille a été évaluée comme faible pour Anthos clusters on AWS.

Que dois-je faire ?

Pour résoudre cette faille, mettez à niveau votre cluster vers une version incluant le correctif. Les versions ultérieures de Anthos clusters on VMware devraient inclure le correctif pour cette faille :

  • Anthos clusters sur AWS 1.4.1-gke.17

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif résout la faille suivante : CVE-2020-8558.

Faible

GCP-2020-009

Date de publication : 15/07/2020
Référence : CVE-2020-8559

GKE

Description Gravité

Une faille d'élévation des privilèges, CVE-2020-8559, a été récemment détectée dans Kubernetes. Cette faille permet à un pirate informatique ayant déjà compromis un nœud d'exécuter une commande dans n'importe quel pod du cluster. Le pirate peut ainsi utiliser le nœud déjà compromis pour en compromettre d'autres et potentiellement lire des informations, ou provoquer des actions de destruction.

Notez que pour qu'un pirate informatique puisse exploiter cette faille, un nœud de votre cluster doit déjà avoir été compromis. Cette faille, en elle-même, ne compromettra pas les nœuds de votre cluster.

Que dois-je faire ?

Mettez à jour votre cluster vers une version corrigée. Les clusters seront mis à jour automatiquement au cours des prochaines semaines, et des versions corrigées seront disponibles d'ici le 19 juillet 2020 en suivant un calendrier accéléré des mises à jour manuelles. Les versions suivantes du plan de contrôle GKE et les versions plus récentes contiennent un correctif permettant de remédier à cette faille :

  • 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+

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8559. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle nécessite que le pirate informatique ait préalablement reçu des informations personnelles sur le cluster, les nœuds et les charges de travail pour réaliser efficacement cette attaque en plus de disposer d'un nœud compromis. Cette faille en elle-même ne fournit pas un nœud compromis au pirate informatique.

Moyen

Clusters Anthos sur

Description Gravité

Une faille d'élévation des privilèges, CVE-2020-8559, a été récemment détectée dans Kubernetes. Cette faille permet à un pirate informatique ayant déjà compromis un nœud d'exécuter une commande dans n'importe quel pod du cluster. Le pirate peut ainsi utiliser le nœud déjà compromis pour en compromettre d'autres et potentiellement lire des informations, ou provoquer des actions de destruction.

Notez que pour qu'un pirate informatique puisse exploiter cette faille, un nœud de votre cluster doit déjà avoir été compromis. Cette faille, en elle-même, ne compromettra pas les nœuds de votre cluster.

Que dois-je faire ?

Mettez à niveau votre cluster vers une version corrigée. Les versions à venir Anthos clusters on VMware suivantes ou les versions ultérieures contiennent le correctif corrigé pour cette faille :

  • Anthos 1.3.3
  • Anthos 1.4.1

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8559. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle nécessite que le pirate informatique ait préalablement reçu des informations personnelles sur le cluster, les nœuds et les charges de travail pour réaliser efficacement cette attaque en plus de disposer d'un nœud compromis. Cette faille en elle-même ne fournit pas un nœud compromis au pirate informatique.

Moyen

Clusters Anthos sur

Description Gravité

Une faille d'élévation des privilèges, CVE-2020-8559, a été récemment détectée dans Kubernetes. Cette faille permet à un pirate informatique ayant déjà compromis un nœud d'exécuter une commande dans n'importe quel pod du cluster. Le pirate peut ainsi utiliser le nœud déjà compromis pour en compromettre d'autres et potentiellement lire des informations, ou provoquer des actions de destruction.

Notez que pour qu'un pirate informatique puisse exploiter cette faille, un nœud de votre cluster doit déjà avoir été compromis. Cette faille, en elle-même, ne compromettra pas les nœuds de votre cluster.

Que dois-je faire ?

La version en disponibilité générale d'Anthos clusters sur AWS (1.4.1, disponible fin juillet 2020) ou une version ultérieure, inclut le correctif de cette faille. Si vous utilisez une version précédente, téléchargez une nouvelle version de l'outil de ligne de commande anthos-gke, puis recréez vos clusters de gestion et d'utilisateur.

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8559. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle nécessite que le pirate informatique ait préalablement reçu des informations personnelles sur le cluster, les nœuds et les charges de travail pour réaliser efficacement cette attaque en plus de disposer d'un nœud compromis. Cette faille en elle-même ne fournit pas un nœud compromis au pirate informatique.

Moyen

GCP-2020-007

Date de publication : 01-06-2020
Référence : CVE-2020-8555

GKE

Description Gravité

La faille SSRF (Server Side Request Forgery) CVE-2020-8555 a été détectée dans Kubernetes. Elle permet à certains utilisateurs autorisés de divulguer jusqu'à 500 octets d'informations sensibles à partir du réseau hôte du plan de contrôle. Le plan de contrôle de Google Kubernetes Engine (GKE) utilise des contrôleurs Kubernetes. Il est donc concerné par cette faille. Nous vous recommandons de mettre à jour le plan de contrôle en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous. Aucune mise à niveau de nœud n'est requise.

Que dois-je faire ?

Pour la plupart des clients, aucune action n'est requise. La grande majorité des clusters exécutent déjà une version corrigée. Les versions de GKE suivantes, ainsi que les versions ultérieures, contiennent le correctif de cette faille :
  • 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

Les clusters qui ont recours à des canaux de publication utilisent déjà les versions du plan de contrôle permettant de réduire les risques liés à la faille.

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8555. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle était difficile à exploiter en raison des diverses mesures de renforcement des plans de contrôle.

Un pirate informatique autorisé à créer un pod avec certains types de volumes intégrés (comme GlusterFS, Quobyte, StorageFS ou ScaleIO) ou à créer un objet StorageClass, peut activer l'envoi de requêtes GET ou POST par kube-controller-manager sans que le corps de la requête contrôlée par le pirate provienne du réseau hôte du maître. Ces types de volumes étant rarement employés sur GKE, leur utilisation récente constitue un bon signal de détection.

Associés à des moyens permettant de partager les résultats de la commande GET/POST avec le pirate (via des journaux, par exemple), ils peuvent entraîner la divulgation d'informations sensibles. Nous avons mis à jour les pilotes de stockage concernés afin de supprimer les risques de telles divulgations.

Moyen

Clusters Anthos sur

Description Gravité

La faille SSRF (Server Side Request Forgery) CVE-2020-8555 a été détectée dans Kubernetes. Elle permet à certains utilisateurs autorisés de divulguer jusqu'à 500 octets d'informations sensibles à partir du réseau hôte du plan de contrôle. Le plan de contrôle de Google Kubernetes Engine (GKE) utilise des contrôleurs Kubernetes. Il est donc concerné par cette faille. Nous vous recommandons de mettre à niveau le plan de contrôle en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous. Aucune mise à niveau de nœud n'est requise.

Que dois-je faire ?

Les versions d'Anthos clusters on VMware suivantes ou des versions ultérieures contiennent le correctif pour cette faille :

  • Anthos 1.3.0

Si vous utilisez une version précédente, mettez à niveau votre cluster existant vers une version bénéficiant du correctif.

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8555. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle était difficile à exploiter en raison des diverses mesures de renforcement des plans de contrôle.

Un pirate informatique autorisé à créer un pod avec certains types de volumes intégrés (comme GlusterFS, Quobyte, StorageFS ou ScaleIO) ou à créer un objet StorageClass, peut activer l'envoi de requêtes GET ou POST par kube-controller-manager sans que le corps de la requête contrôlée par le pirate provienne du réseau hôte du maître. Ces types de volumes étant rarement employés sur GKE, leur utilisation récente constitue un bon signal de détection.

Associés à des moyens permettant de partager les résultats de la commande GET/POST avec le pirate (via des journaux, par exemple), ils peuvent entraîner la divulgation d'informations sensibles. Nous avons mis à jour les pilotes de stockage concernés afin de supprimer les risques de telles divulgations.

Moyen

Clusters Anthos sur

Description Gravité

La faille SSRF (Server Side Request Forgery) CVE-2020-8555 a été détectée dans Kubernetes. Elle permet à certains utilisateurs autorisés de divulguer jusqu'à 500 octets d'informations sensibles à partir du réseau hôte du plan de contrôle. Le plan de contrôle de Google Kubernetes Engine (GKE) utilise des contrôleurs Kubernetes. Il est donc concerné par cette faille. Nous vous recommandons de mettre à niveau le plan de contrôle en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous. Aucune mise à niveau de nœud n'est requise.

Que dois-je faire ?

Anthos clusters sur AWS (GKE sur AWS) v0.2.0 ou une version ultérieure inclut déjà le correctif de cette faille. Si vous utilisez une version précédente, téléchargez une nouvelle version de l'outil de ligne de commande anthos-gke, puis recréez vos clusters de gestion et d'utilisateur.

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille CVE-2020-8555. La gravité de cette faille est évaluée comme moyenne pour GKE, car elle était difficile à exploiter en raison des diverses mesures de renforcement des plans de contrôle.

Un pirate informatique autorisé à créer un pod avec certains types de volumes intégrés (comme GlusterFS, Quobyte, StorageFS ou ScaleIO) ou à créer un objet StorageClass, peut activer l'envoi de requêtes GET ou POST par kube-controller-manager sans que le corps de la requête contrôlée par le pirate provienne du réseau hôte du maître. Ces types de volumes étant rarement employés sur GKE, leur utilisation récente constitue un bon signal de détection.

Associés à des moyens permettant de partager les résultats de la commande GET/POST avec le pirate (via des journaux, par exemple), ils peuvent entraîner la divulgation d'informations sensibles. Nous avons mis à jour les pilotes de stockage concernés afin de supprimer les risques de telles divulgations.

Moyen

GCP-2020-006

Date de publication : 01-06-2020
Référence : Problème Kubernetes 91507

GKE

Description Gravité

Kubernetes a divulgué une faille qui permet à un conteneur privilégié de rediriger le trafic de nœuds vers un autre conteneur. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque. Tous les nœuds Google Kubernetes Engine (GKE) sont affectés par cette faille. Par conséquent, nous vous recommandons de procéder à la mise à niveau en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous.

Que dois-je faire ?

Pour réduire les risques liés à cette faille, mettez votre plan de contrôle, puis vos nœuds en installant l'une des versions corrigées répertoriées ci-dessous. Les clusters situés sur des canaux de publication exécutent déjà une version corrigée aussi bien sur le plan de contrôle que sur les nœuds :
  • 1.14.10-gke.36
  • 1.15.11-gke.15
  • 1.16.8-gke.15

Très peu de conteneurs nécessitent généralement CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via PodSecurityPolicy ou Anthos Policy Controller :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
        # 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
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
        # 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"
  • Ou en mettant à jour les spécifications du pod :
    
        # 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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille décrite dans l'article Problème Kubernetes 91507 est liée à la fonctionnalité CAP_NET_RAW (qui fait partie de l'ensemble de fonctionnalités par défaut du conteneur). Elle configure de manière malveillante la pile IPv6 sur le nœud, et redirige le trafic de nœuds vers le conteneur contrôlé par le pirate. Cela permet au pirate d'intercepter ou de modifier le trafic en provenance du nœud ou à destination de celui-ci. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque.

Moyen

Clusters Anthos sur

Description Gravité

Kubernetes a divulgué une faille qui permet à un conteneur privilégié de rediriger le trafic de nœuds vers un autre conteneur. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque. Tous les nœuds Google Kubernetes Engine (GKE) sont affectés par cette faille. Par conséquent, nous vous recommandons de procéder à la mise à niveau en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous.

Que dois-je faire ?

Pour atténuer cette faille pour Anthos clusters on VMware (GKE On-Prem), mettez à niveau les clusters vers la version suivante ou une version plus récente :
  • Anthos 1.3.2

Très peu de conteneurs nécessitent généralement CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via Anthos Policy Controller ou en mettant à jour les spécifications du pod :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
        # 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
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
        # 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"
  • Ou en mettant à jour les spécifications du pod :
    
        # 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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille décrite dans l'article Problème Kubernetes 91507 est liée à la fonctionnalité CAP_NET_RAW (qui fait partie de l'ensemble de fonctionnalités par défaut du conteneur). Elle configure de manière malveillante la pile IPv6 sur le nœud, et redirige le trafic de nœuds vers le conteneur contrôlé par le pirate. Cela permet au pirate d'intercepter ou de modifier le trafic en provenance du nœud ou à destination de celui-ci. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque.

Moyen

Clusters Anthos sur

Description Gravité

Kubernetes a divulgué une faille qui permet à un conteneur privilégié de rediriger le trafic de nœuds vers un autre conteneur. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque. Tous les nœuds Google Kubernetes Engine (GKE) sont affectés par cette faille. Par conséquent, nous vous recommandons de procéder à la mise à niveau en installant la dernière version du correctif, conformément à la procédure expliquée ci-dessous.

Que dois-je faire ?

Téléchargez l'outil de ligne de commande anthos-gke avec la version suivante ou ultérieure, puis recréez vos clusters de gestion et d'utilisateur :

  • aws-0.2.1-gke.7

Très peu de conteneurs nécessitent généralement CAP_NET_RAW. Il faut donc la bloquer par défaut, ainsi que d'autres fonctionnalités puissantes, via Anthos Policy Controller ou en mettant à jour les spécifications du pod :

Supprimez la fonctionnalité CAP_NET_RAW des conteneurs à l'aide de l'une des méthodes suivantes :

  • Appliquez le blocage de ces fonctionnalités avec PodSecurityPolicy, par exemple :
    
        # 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
  • Ou en utilisant Policy Controller ou Gatekeeper avec ce modèle de contrainte et en l'appliquant, par exemple :
    
        # 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"
  • Ou en mettant à jour les spécifications du pod :
    
        # 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

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille décrite dans l'article Problème Kubernetes 91507 est liée à la fonctionnalité CAP_NET_RAW (qui fait partie de l'ensemble de fonctionnalités par défaut du conteneur). Elle configure de manière malveillante la pile IPv6 sur le nœud, et redirige le trafic de nœuds vers le conteneur contrôlé par le pirate. Cela permet au pirate d'intercepter ou de modifier le trafic en provenance du nœud ou à destination de celui-ci. Le trafic TLS/SSH mutuel (entre le kubelet et le serveur d'API, ou en provenance d'applications via le protocole mTLS) ne peut pas être lu ni modifié par cette attaque.

Moyen

GCP-2020-005

Date de publication : 07-05-2020
Dernière mise à jour : 07-05-2020
Référence : CVE-2020-8835

GKE

Description Gravité

La faille CVE-2020-8835 a été récemment découverte dans le noyau Linux. Elle permet de "s'échapper d'un conteneur" pour obtenir un accès root (racine) sur le nœud hôte.

Cette faille affecte les nœuds Ubuntu exécutant Google Kubernetes Engine (GKE) version 1.16 ou 1.17. Nous vous recommandons donc d'effectuer dès que possible une mise à niveau en installant la dernière version du correctif, conformément à la procédure décrite ci-dessous.

Les nœuds exécutant Container-Optimized OS ne sont pas concernés, Les nœuds s'exécutant sur des clusters Anthos sur VMware ne sont pas affectés.

Que dois-je faire ?

Pour la plupart des clients, aucune action n'est requise. Seuls les nœuds Ubuntu exécutant GKE version 1.16 ou 1.17 sont concernés.

Avant tout, vous devez mettre à niveau votre nœud maître vers la toute dernière version. Le correctif sera disponible dans Kubernetes 1.16.8-gke.12 et 1.17.4-gke.10, ainsi que dans les versions ultérieures. Pour vérifier la disponibilité de ces correctifs, consultez les notes de version.

Quelle faille ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés à la faille suivante :

La faille CVE-2020-8835 affecte les versions 5.5.0 et ultérieures du noyau Linux. Elle permet à un conteneur malveillant d'accéder en lecture et en écriture à la mémoire du noyau, et ainsi d'exécuter des codes avec un accès root par le biais d'un simple appel système "exec". La gravité de cette faille est évaluée comme élevée.

Élevé

GCP-2020-004

Date de publication : 07-05-2020
Dernière mise à jour : 07-05-2020
Référence : CVE-2019-11254

Clusters Anthos sur

Description Gravité

La faille CVE-2019-11254 a été récemment découverte dans Kubernetes. Elle permet à tout utilisateur autorisé d'effectuer des requêtes POST afin de réaliser une attaque par déni de service à distance sur un serveur d'API Kubernetes. Le comité de sécurité des produits (PSC, Product Security Committee) Kubernetes a publié des informations complémentaires sur cette faille. Pour les consulter, cliquez ici.

Vous pouvez réduire les risques liés à cette faille en limitant les clients disposant d'un accès réseau à vos serveurs d'API Kubernetes.

Que dois-je faire ?

Nous vous recommandons de mettre à jour vos clusters vers des versions contenant le correctif permettant de remédier à cette faille dès que ces versions seront disponibles.

Les versions qui contiennent le correctif sont indiquées ci-dessous :

  • Anthos 1.3.0, qui exécute la version 1.15.7-gke.32 de Kubernetes

Quelles failles ce correctif permet-il de résoudre ?

Ce correctif permet de résoudre la faille de déni de service (DoS) suivante :

CVE-2019-11254.

Moyen

GCP-2020-003

Date de publication : 31-03-2020
Dernière mise à jour : 31-03-2020
Référence : CVE-2019-11254

GKE

Description Gravité

La faille CVE-2019-11254 a été récemment découverte dans Kubernetes. Elle permet à tout utilisateur autorisé d'effectuer des requêtes POST afin de réaliser une attaque par déni de service à distance sur un serveur d'API Kubernetes. Le comité de sécurité des produits (PSC, Product Security Committee) Kubernetes a publié des informations complémentaires sur cette faille. Pour les consulter, cliquez ici.

Les clusters GKE qui utilisent des réseaux autorisés maîtres et des clusters privés sans accès à un point de terminaison public réduisent les risques liés à cette faille.

Que dois-je faire ?

Nous vous recommandons de mettre à niveau votre cluster vers une version du correctif permettant de remédier à cette faille.

Les versions du correctif correspondantes sont indiquées ci-dessous :

  • 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

Quelles failles ce correctif permet-il de résoudre ?

Ce correctif permet de résoudre la faille de déni de service (DoS) suivante :

CVE-2019-11254.

Moyen

GCP-2020-002

Date de publication : 23-03-2020
Dernière mise à jour : 23-03-2020
Référence : CVE-2020-8551, CVE-2020-8552

GKE

Description Gravité

La communauté Kubernetes a divulgué deux failles de déni de service, l'une affectant le serveur d'API et l'autre ayant des conséquences sur les kubelets. Pour en savoir plus, reportez-vous aux problèmes Kubernetes 89377 et 89378.

Que dois-je faire ?

Tous les utilisateurs de GKE sont protégés contre la faille CVE-2020-8551 tant que les utilisateurs non approuvés ne peuvent pas envoyer de requêtes au sein du réseau interne du cluster. L'utilisation des réseaux autorisés maîtres réduit également les risques liés à la faille CVE-2020-8552.

Quand des correctifs seront-ils appliqués ?

Les correctifs de la faille CVE-2020-8551 nécessitent une mise à niveau des nœuds. Les versions du correctif permettant de réduire les risques liés à cette faille sont indiquées ci-dessous :

  • 1.15.10-gke*
  • 1.16.7-gke*

Les correctifs de la faille CVE-2020-8552 nécessitent une mise à niveau du maître. Les versions du correctif permettant de réduire les risques liés à cette faille sont indiquées ci-dessous :

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

21 janvier 2020

Date de publication : 21-01-2020
Dernière mise à jour : 24-01-2020
Référence : CVE-2019-11254

GKE

Description Gravité

Mise à jour du 24/01/2020 : le processus de mise à disposition des versions corrigées est en cours et devrait s'achever le 25 janvier 2020.


Microsoft a révélé la présence d'une faille dans l'API Windows Crypto et son processus de validation des signatures à courbes elliptiques. Pour en savoir plus, consultez le communiqué de Microsoft.

Que dois-je faire ?

Pour la plupart des clients, aucune action n'est requise. Seuls les nœuds qui exécutent Windows Server sont concernés.

Les clients qui utilisent les nœuds Windows Server doivent mettre à jour à la fois les nœuds et les charges de travail en conteneur exécutées sur ceux-ci, en installant les versions corrigées pour réduire les risques liés à cette faille.

Pour mettre à jour les conteneurs, procédez comme suit :

Recréez vos conteneurs à l'aide des dernières images de conteneurs de base de Microsoft. Pour cela, sélectionnez un tag servercore ou nanoserver dont la mise à jour la plus récente a été effectuée le 14 janvier 2020 ou après cette date.

Pour mettre à jour les nœuds, procédez comme suit :

Le processus de mise à disposition des versions corrigées est en cours et s'achèvera d'ici le 24 janvier 2020.

Vous pouvez soit patienter jusqu'à cette date et effectuer une mise à jour des nœuds en installant une version corrigée de GKE, soit utiliser Windows Update pour déployer le dernier correctif Windows manuellement à tout moment.

Vous trouverez ci-dessous la liste des versions du correctif permettant de réduire les risques liés à cette faille :

  • 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

Quelles failles ce correctif permet-il de résoudre ?

Ce correctif réduit les risques liés aux failles suivantes :

CVE-2020-0601 (aussi appelée la faille de spoofing de l'API Windows Crypto) : un pirate peut l'exploiter pour faire en sorte que ses fichiers exécutables malveillants soient considérés comme fiables ou encore pour procéder à des attaques de type MITM ("man in the middle") afin de déchiffrer des informations confidentielles diffusées via les connexions TLS associées aux logiciels concernés par la faille.

Score de base NVD : 8,1 (élevé)

Bulletins de sécurité archivés

Pour les bulletins de sécurité antérieurs à 2020, consultez l'archive des bulletins de sécurité.