Bulletins de sécurité

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 sur Azure
  • 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.

Lorsque GKE émet un bulletin de sécurité directement lié à la configuration ou à la version de votre cluster, nous pouvons vous envoyer une notification de cluster SecurityBulletinEvent qui fournit des informations sur la faille et les actions que vous pouvez entreprendre, le cas échéant. Pour en savoir plus sur la configuration des notifications de cluster, consultez la page Notifications de cluster.

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

Les plates-formes GKE et Anthos n'utilisent pas de composants tels que ingress-nginx ou l'environnement d'exécution de conteneur CRI-O, et ne sont donc pas affectées par les failles associées à ces composants. Si vous installez des composants à partir d'autres sources, reportez-vous à la source en question pour les mises à jour de sécurité ainsi que pour obtenir des conseils eu égard aux correctifs associés à ces composants.

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

GCP-2022-018

Date de publication : 2022-08-01
Référence : CVE-2022-2327

GKE

Description Gravité

Une nouvelle faille (CVE-2022-2327) a été détectée dans le noyau Linux, qui peut entraîner l'élévation des privilèges locaux. Cette faille permet à un utilisateur non privilégié d'échapper complètement au conteneur pour arriver à la racine du nœud.

Détails techniques

Les clusters GKE, y compris les clusters Autopilot, avec Container-Optimized OS (COS) avec Linux Kernel version 5.10, sont concernés. Les clusters GKE utilisant des images Ubuntu ou GKE Sandbox ne sont pas affectés.

Que dois-je faire ?

Mettez à niveau vos clusters GKE vers une version incluant le correctif. Les images de nœuds Linux pour COS ont été mises à jour avec les versions de GKE utilisant ces versions COS.

Pour des raisons de sécurité, même si la mise à niveau automatique des nœuds est activée, nous vous recommandons de mettre à niveau manuellement vos pools de nœuds vers l'une des versions GKE suivantes :

Versions de COS

  • 1.22.12-gke.300
  • 1.23.8-gke.1900
  • 1.24.2-gke.1900


Une fonctionnalité récente des canaux de publication vous permet d'appliquer un correctif sans avoir à vous désabonner d'un canal. Cela vous permet de mettre à niveau vos nœuds vers la version corrigée avant que cette version ne devienne la version par défaut de la version disponible sélectionnée.

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

Avec CVE-2022-2327, le noyau Linux de la version 5.10 présente une faille dans le sous-système "io_uring", où diverses requêtes ne disposent pas de type d'élément (options). L'utilisation de ces requêtes sans spécifier les types d'éléments appropriés peut entraîner l'élévation des privilèges à la racine.
High

clusters Anthos sur VMware

Description Gravité

Une nouvelle faille (CVE-2022-2327) a été détectée dans le noyau Linux, qui peut entraîner l'élévation des privilèges locaux. Cette faille permet à un utilisateur non privilégié d'échapper complètement au conteneur pour arriver à la racine du nœud.

Les clusters avec une image Container-Optimized OS (COS) utilisant des clusters Anthos sur VMware version 1.10, 1.11 et 1.12 sont concernés.

Que dois-je faire ?

Des versions des clusters Anthos sur VMware contenant des correctifs seront bientôt disponibles. Ce bulletin de sécurité sera mis à jour lorsque les versions des clusters Anthos sur VMware seront disponibles en téléchargement.

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

Avec CVE-2022-2327, le noyau Linux de la version 5.10 présente une faille dans le sous-système "io_uring", où diverses requêtes ne disposent pas de type d'élément (options). L'utilisation de ces requêtes sans spécifier les types d'éléments appropriés peut entraîner l'élévation des privilèges à la racine.

High

Anthos clusters on AWS

Description Gravité

Une nouvelle faille (CVE-2022-2327) a été détectée dans le noyau Linux, qui peut entraîner l'élévation des privilèges locaux. Cette faille permet à un utilisateur non privilégié d'échapper complètement au conteneur pour arriver à la racine du nœud.

Que dois-je faire ?

Des versions des clusters Anthos sur AWS contenant des correctifs seront bientôt publiées. Ce bulletin de sécurité sera mis à jour lorsque les versions des clusters Anthos sur AWS seront disponibles en téléchargement.

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

Avec CVE-2022-2327, le noyau Linux de la version 5.10 présente une faille dans le sous-système "io_uring", où diverses requêtes ne disposent pas de type d'élément (options). L'utilisation de ces requêtes sans spécifier les types d'éléments appropriés peut entraîner l'élévation des privilèges à la racine.

High

Anthos sur Azure

Description Gravité

Une nouvelle faille (CVE-2022-2327) a été détectée dans le noyau Linux, qui peut entraîner l'élévation des privilèges locaux. Cette faille permet à un utilisateur non privilégié d'échapper complètement au conteneur pour arriver à la racine du nœud.

Que dois-je faire ?

Des versions d'Anthos sur Azure contenant des correctifs seront bientôt disponibles. Ce bulletin de sécurité sera mis à jour lorsque les versions d'Anthos sur Azure seront disponibles en téléchargement.

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

Avec CVE-2022-2327, le noyau Linux de la version 5.10 présente une faille dans le sous-système "io_uring", où diverses requêtes ne disposent pas de type d'élément (options). L'utilisation de ces requêtes sans spécifier les types d'éléments appropriés peut entraîner l'élévation des privilèges à la racine.

High

Anthos sur solution Bare Metal

Description Gravité

Une nouvelle faille (CVE-2022-2327) a été détectée dans le noyau Linux, qui peut entraîner l'élévation des privilèges locaux. Cette faille permet à un utilisateur non privilégié d'échapper complètement au conteneur pour arriver à la racine du nœud.

Que dois-je faire ?

Aucune action n'est requise. Anthos sur solution Bare Metal n'est pas affecté par cette faille CVE, car il n'intègre pas de système d'exploitation dans sa distribution.

Aucune

GCP-2022-017

Date de publication : 29/06/2022
Dernière mise à jour : 21/07/2022
Référence : CVE-2022-1786

Mise à jour du 21/07/2022 : informations mises à jour indiquant que les images COS Clusters Anthos sur VMware sont affectées.

GKE

Description Gravité

Une nouvelle faille (CVE-2022-1786) a été détectée dans les versions de noyau Linux 5.10 et 5.11. Cette faille permet à un utilisateur non privilégié disposant d'un accès local au cluster de s'échapper d'un conteneur pour obtenir un accès racine au nœud. Seuls les clusters qui exécutent Container-Optimized OS sont affectés. Les versions d'Ubuntu GKE utilisent la version 5.4 ou 5.15 du noyau et ne sont pas affectées.

Que dois-je faire ?

Les versions des images de nœuds Linux pour Container-Optimized OS pour les versions suivantes de GKE ont été mises à jour avec du code pour corriger cette faille. Pour des raisons de sécurité, même si la mise à niveau automatique des nœuds est activée, nous vous recommandons de mettre à niveau manuellement vos pools de nœuds vers l'une des versions futures de GKE ci-dessous :

  • 1.22.10-gke.600
  • 1.23.7-gke.1400
  • 1.24.1-gke.1400

Une fonctionnalité récente des canaux de publication vous permet d'appliquer un correctif sans avoir à vous désabonner d'un canal. Cela vous permet de mettre à niveau vos nœuds vers la version corrigée avant que cette version ne devienne la version par défaut de la version disponible sélectionnée.

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

La faille CVE-2022-1786 a révélé une faille après l'utilisation gratuite dans le sous-système io_uring du noyau Linux. Si un utilisateur configure un anneau avec IORING_SETUP_IOPOLL avec plusieurs tâches terminées sur l'anneau, un utilisateur local peut planter ou augmenter ses droits sur le système.

High

clusters Anthos sur VMware

Mise à jour : 14/07/2022

Description Gravité

Une nouvelle faille (CVE-2022-1786) a été détectée dans les versions de noyau Linux 5.10 et 5.11. Cette faille permet à un utilisateur non privilégié disposant d'un accès local au cluster de s'échapper d'un conteneur pour obtenir un accès racine au nœud.

Que dois-je faire ?

Mise à jour du 21/07/2022 : le code des versions suivantes des clusters Anthos sur VMware a été mis à jour pour corriger cette faille.

COS
  • 1.10.5 ou ultérieure
  • 1.11.2 ou ultérieure
  • 1.12.0 ou ultérieure

Ubuntu

Aucune action n'est requise. Anthos clusters sur VMware n'utilise pas les versions concernées du noyau Linux.

None

Anthos clusters on AWS

Description Gravité

Une nouvelle faille (CVE-2022-1786) a été détectée dans les versions de noyau Linux 5.10 et 5.11. Cette faille permet à un utilisateur non privilégié disposant d'un accès local au cluster de s'échapper d'un conteneur pour obtenir un accès racine au nœud.

Que dois-je faire ?

Aucune action n'est requise. Les clusters Anthos sur AWS n'utilisent pas les versions concernées du noyau Linux.

None

Anthos on Azure

Description Gravité

Une nouvelle faille (CVE-2022-1786) a été détectée dans les versions de noyau Linux 5.10 et 5.11. Cette faille permet à un utilisateur non privilégié disposant d'un accès local au cluster de s'échapper d'un conteneur pour obtenir un accès racine au nœud.

Que dois-je faire ?

Aucune action n'est requise. Anthos sur Azure n'utilise pas les versions concernées du noyau Linux.

None

Anthos sur solution Bare Metal

Description Gravité

Une nouvelle faille (CVE-2022-1786) a été détectée dans les versions de noyau Linux 5.10 et 5.11. Cette faille permet à un utilisateur non privilégié disposant d'un accès local au cluster de s'échapper d'un conteneur pour obtenir un accès racine au nœud.

Que dois-je faire ?

Aucune action n'est requise. Anthos sur solution Bare Metal n'est pas affecté par cette faille, car il n'intègre pas de système d'exploitation dans sa distribution.

None

GCP-2022-016

Date de publication : 23-06-2022
Dernière mise à jour : 29-07-2022
Référence : CVE-2022-29581, CVE-2022-29582, CVE-2022-1116

Mise à jour du 29-07-2022 : versions mises à jour des clusters Anthos sur VMware, Anthos sur AWS et Anthos sur Azure.

GKE

Dernière mise à jour : 29-07-2022

Description Gravité

Mise à jour du 29-07-2022 : les pods utilisant GKE Sandbox ne sont pas vulnérables à ces failles.


Trois nouvelles failles de corruption de mémoire (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) ont été détectées dans le noyau Linux. Ces failles permettent à un utilisateur non privilégié disposant d'un accès local au cluster de s'en échapper complètement pour arriver à la racine du nœud. Tous les clusters Linux (Container-Optimized OS et Ubuntu) sont affectés.

Que dois-je faire ?

Les versions des images de nœuds Linux pour Container-Optimized OS et Ubuntu pour les versions suivantes de GKE ont été mises à jour avec du code pour corriger cette faille. Pour des raisons de sécurité, même si la mise à niveau automatique des nœuds est activée, nous vous recommandons de mettre à niveau manuellement vos pools de nœuds vers l'une des versions de GKE suivantes :

  • Container-Optimized OS :
    • 1.19.16-gke.13800
    • 1.20.15-gke.8000
    • 1.21.12-gke.1500
    • 1.22.9-gke.1300
    • 1.23.6-gke.1500
    • 1.24.1-gke.1400
  • Ubuntu :
    • 1.20.15-gke.9600
    • 1.21.13-gke.900
    • 1.22.10-gke.600
    • 1.23.7-gke.1400
    • 1.24.1-gke.1400

Une fonctionnalité récente des canaux de publication vous permet d'appliquer un correctif sans avoir à vous désabonner d'un canal. Cela vous permet de mettre à niveau vos nœuds vers la version corrigée avant que cette version ne devienne la version par défaut de la version disponible sélectionnée.

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

Avec la faille CVE-2022-29582, le noyau Linux des versions antérieures à 5.17.3 permet une utilisation après la période gratuite en raison d'une condition de concurrence dans les délais avant expiration io_uring.

Les failles CVE-2022-29581 et CVE-2022-1116 sont des failles qui permettent à un pirate informatique local de provoquer une corruption de mémoire dans io_uring ou net/sched dans le noyau Linux, et ainsi d'élever les privilèges au niveau racine.

High

clusters Anthos sur VMware

Dernière mise à jour : 29-07-2022

Description Gravité

Mise à jour du 29-07-2022 : les versions suivantes des clusters Anthos sur VMware contiennent du code qui corrige ces failles.

  • 1.9.7 ou ultérieure
  • 1.10.5 ou ultérieure
  • 1.11.2 ou ultérieure
  • 1.12.0 ou ultérieure


Trois nouvelles failles de corruption de mémoire (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) ont été détectées dans le noyau Linux. Ces failles permettent à un utilisateur non privilégié disposant d'un accès local au cluster de s'en échapper complètement pour arriver à la racine du nœud. Ces failles affectent Anthos clusters on VMware v1.9 et versions ultérieures pour les images Container-Optimized OS et Ubuntu.

Que dois-je faire ?

Des versions des clusters Anthos sur VMware contenant des correctifs seront bientôt disponibles. Ce bulletin de sécurité sera mis à jour lorsque les versions des clusters Anthos sur VMware seront disponibles en téléchargement.

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

Avec la faille CVE-2022-29582, le noyau Linux des versions antérieures à 5.17.3 permet une utilisation après la période gratuite en raison d'une condition de concurrence dans les délais avant expiration io_uring.

Les failles CVE-2022-29581 et CVE-2022-1116 sont des failles qui permettent à un pirate informatique local de provoquer une corruption de mémoire dans io_uring ou net/sched dans le noyau Linux, et ainsi d'élever les privilèges au niveau racine.

High

Clusters Anthos sur AWS

Dernière mise à jour : 29-07-2022

Description Gravité

Mise à jour du 29-07-2022 : les versions précédentes et actuelles des clusters Anthos sur AWS ci-dessous ont été mises à jour avec du code pour corriger ces failles. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions des clusters Anthos sur AWS suivantes :

Génération actuelle :

  • 1.23.7-gke.1300
  • 1.22.10-gke.1500
  • 1.21.11-gke.1900
Génération précédente :
  • 1.23.7-gke.1500
  • 1.22.10-gke.1500
  • 1.21.13-gke.1600

Trois nouvelles failles de corruption de mémoire (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) ont été détectées dans le noyau Linux. Ces failles permettent à un utilisateur non privilégié disposant d'un accès local au cluster de s'en échapper complètement pour arriver à la racine du nœud. Ces failles affectent toutes les versions des clusters Anthos sur AWS.

Que dois-je faire ?

Des versions des clusters Anthos sur AWS contenant des correctifs seront bientôt publiées. Ce bulletin de sécurité sera mis à jour lorsque les versions des clusters Anthos sur AWS seront disponibles en téléchargement.

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

Avec la faille CVE-2022-29582, le noyau Linux des versions antérieures à 5.17.3 permet une utilisation après la période gratuite en raison d'une condition de concurrence dans les délais avant expiration io_uring.

Les failles CVE-2022-29581 et CVE-2022-1116 sont des failles qui permettent à un pirate informatique local de provoquer une corruption de mémoire dans io_uring ou net/sched dans le noyau Linux, et ainsi d'élever les privilèges au niveau racine.

High

Anthos sur Azure

Description Gravité

Mise à jour du 29-07-2022 : les versions suivantes d'Anthos sur Azure ont été mises à jour avec du code pour corriger ces failles. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions d'Anthos on Azure suivantes :

  • 1.23.7-gke.1300
  • 1.22.10-gke.1500
  • 1.21.11-gke.1900


Trois nouvelles failles de corruption de mémoire (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) ont été détectées dans le noyau Linux. Ces failles permettent à un utilisateur non privilégié disposant d'un accès local au cluster de s'en échapper complètement pour arriver à la racine du nœud. Ces failles affectent toutes les versions d'Anthos on Azure.

Que dois-je faire ?

Des versions d'Anthos sur Azure contenant des correctifs seront bientôt disponibles. Ce bulletin de sécurité sera mis à jour lorsque les versions d'Anthos sur Azure seront disponibles en téléchargement.

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

Avec la faille CVE-2022-29582, le noyau Linux des versions antérieures à 5.17.3 permet une utilisation après la période gratuite en raison d'une condition de concurrence dans les délais avant expiration io_uring.

Les failles CVE-2022-29581 et CVE-2022-1116 sont des failles qui permettent à un pirate informatique local de provoquer une corruption de mémoire dans io_uring ou net/sched dans le noyau Linux, et ainsi d'élever les privilèges au niveau racine.

High

Anthos sur solution Bare Metal

Description Gravité

Trois nouvelles failles de corruption de mémoire (CVE-2022-29581, CVE-2022-29582, CVE-2022-1116) ont été détectées dans le noyau Linux. Ces failles permettent à un utilisateur non privilégié disposant d'un accès local au cluster de s'en échapper complètement pour arriver à la racine du nœud.

Que dois-je faire ?

Aucune action n'est requise. Anthos sur solution Bare Metal n'est pas affecté par cette faille, car il n'intègre pas de système d'exploitation dans sa distribution.

None

GCP-2022-014

Date de publication : 26/04/2022
Dernière mise à jour : 12/05/2022

Mise à jour du 12/05/2022 : mises à jour des versions de correctif pour les clusters Anthos sur AWS et les clusters Anthos on Azure.

Référence : CVE-2022-1055, CVE-2022-27666

GKE

Description Gravité

Deux failles de sécurité, CVE-2022-1055 et CVE-2022-27666, ont été détectées dans le noyau Linux. Chacune d'entre elles peut permettre à un pirate informatique local d'effectuer une interruption des conteneurs, une élévation des privilèges sur l'hôte, ou les deux. Ces failles affectent tous les systèmes d'exploitation du nœud GKE (Container-Optimized OS et Ubuntu).

Détails techniques

Dans la faille CVE-2022-1055, un pirate informatique peut exploiter la fonctionnalité use-after-free dans tc_new_tfilter(), ce qui permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Dans la faille CVE-2022-27666, le débordement du tampon dans esp/esp6_output_head permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

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 pour corriger ces failles. Mettez à niveau vos clusters vers l'une des versions suivantes.

  • 1.19.16-gke.11000 et versions ultérieures
  • 1.20.15-gke.5200 et versions ultérieures
  • 1.21.11-gke.1100 et versions ultérieures
  • 1.22.8-gke.200 et versions ultérieures
  • 1.23.5-gke.1500 et versions ultérieures

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

Élevé

clusters Anthos sur VMware

Description Gravité

Deux failles de sécurité, CVE-2022-1055 et CVE-2022-27666, ont été détectées dans le noyau Linux. Chacune d'entre elles peut permettre à un pirate informatique local d'effectuer une interruption des conteneurs, une élévation des privilèges sur l'hôte, ou les deux. Ces failles affectent tous les systèmes d'exploitation du nœud GKE (Container-Optimized OS et Ubuntu).

Détails techniques

Dans la faille CVE-2022-1055, un pirate informatique peut exploiter la fonctionnalité use-after-free dans tc_new_tfilter(), ce qui permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Dans la faille CVE-2022-27666, le débordement du tampon dans esp/esp6_output_head permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Que dois-je faire ?

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

  • 1.9.6 (à venir)
  • 1.10.3
  • 1.11.0 (à venir)

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

Élevé

Anthos clusters on AWS

Dernière mise à jour : 12/05/2022

Description Gravité

Deux failles de sécurité, CVE-2022-1055 et CVE-2022-27666, ont été détectées dans le noyau Linux. Chacune d'entre elles peut permettre à un pirate informatique local d'effectuer une interruption des conteneurs, une élévation des privilèges sur l'hôte, ou les deux. Ces failles affectent tous les systèmes d'exploitation du nœud GKE (Container-Optimized OS et Ubuntu).

Détails techniques

Dans la faille CVE-2022-1055, un pirate informatique peut exploiter la fonctionnalité use-after-free dans tc_new_tfilter(), ce qui permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Dans la faille CVE-2022-27666, le débordement du tampon dans esp/esp6_output_head permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Que dois-je faire ?

Mise à jour du 12/05/2022 : le code des versions suivantes et actuelles des clusters Anthos sur AWS a été mis à jour pour corriger ces failles. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions des clusters Anthos sur AWS suivantes :

Génération actuelle
  • 1.21.11-gke.1100
  • 1.22.8-gke.1300
Génération précédente
  • 1.20.15-gke.5200
  • 1.21.11-gke.1100
  • 1.22.8-gke.1300

Mettez à niveau votre cluster vers une version corrigée. Les correctifs seront disponibles dans une prochaine version. Ce bulletin sera mis à jour dès qu'ils seront disponibles.

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

Élevé

Anthos on Azure

Dernière mise à jour : 12/05/2022

Description Gravité

Deux failles de sécurité, CVE-2022-1055 et CVE-2022-27666, ont été détectées dans le noyau Linux. Chacune d'entre elles peut permettre à un pirate informatique local d'effectuer une interruption des conteneurs, une élévation des privilèges sur l'hôte, ou les deux. Ces failles affectent tous les systèmes d'exploitation du nœud GKE (Container-Optimized OS et Ubuntu).

Détails techniques

Dans la faille CVE-2022-1055, un pirate informatique peut exploiter la fonctionnalité use-after-free dans tc_new_tfilter(), ce qui permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Dans la faille CVE-2022-27666, le débordement du tampon dans esp/esp6_output_head permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Que dois-je faire ?

Mise à jour du 12/05/2022 : le code des versions suivantes d'Anthos on Azure a été mis à jour pour corriger ces failles. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions d'Anthos on Azure suivantes :

  • 1.21.11-gke.1100
  • 1.22.8-gke.1300

Mettez à niveau votre cluster vers une version corrigée. Les correctifs seront disponibles dans une prochaine version. Ce bulletin sera mis à jour dès qu'ils seront disponibles.

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

Élevé

Anthos sur solution Bare Metal

Description Gravité

Deux failles de sécurité, CVE-2022-1055 et CVE-2022-27666, ont été détectées dans le noyau Linux. Chacune d'entre elles peut permettre à un pirate informatique local d'effectuer une interruption des conteneurs, une élévation des privilèges sur l'hôte, ou les deux. Ces failles affectent tous les systèmes d'exploitation du nœud GKE (Container-Optimized OS et Ubuntu).

Détails techniques

Dans la faille CVE-2022-1055, un pirate informatique peut exploiter la fonctionnalité use-after-free dans tc_new_tfilter(), ce qui permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Dans la faille CVE-2022-27666, le débordement du tampon dans esp/esp6_output_head permet à un pirate informatique local dans le conteneur d'élever les privilèges à la racine du nœud.

Que dois-je faire ?

Aucune action n'est requise. Anthos sur solution Bare Metal n'est pas affecté par cette faille CVE, car il n'inclut pas Linux dans son package. Vous devez vous assurer que les images de nœud que vous utilisez sont mises à jour vers les versions contenant les correctifs pour CVE-2022-1055 et CVE-2022-27666.

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

Élevé

GCP-2022-013

Date de publication : 11-04-2022
Dernière mise à jour : 20-04-2022
Référence : CVE-2022-23648
Mise à jour du 22-04-2022 : mise à jour des versions de correctif pour Anthos sur solution Bare Metal et les clusters Anthos sur VMware.

GKE

Description Gravité

Une faille de sécurité, CVE-2022-23648, a été détectée dans la gestion du balayage de chemin d'accès de containerd dans la spécification du volume d'images OCI. Les conteneurs lancés via l'implémentation CRI de containerd avec une configuration d'image spécialement conçue à cet effet peuvent bénéficier d'un accès en lecture complet aux fichiers et répertoires arbitraires de l'hôte.

Cette faille peut contourner toute application basée sur des règles lors de la configuration du conteneur (y compris une stratégie de sécurité des pods Kubernetes). Cette faille affecte tous les systèmes d'exploitation de nœud GKE (Container-Optimized OS et Ubuntu) qui utilisent containerd par défaut. Tous les nœuds GKE, Autopilot et GKE Sandbox sont affectés.

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 pour corriger cette faille. Pour des raisons de sécurité, même si la mise à niveau automatique des nœuds est activée, nous vous recommandons de mettre à niveau manuellement vos nœuds vers l'une des versions de GKE suivantes :

  • 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

Une fonctionnalité récente des canaux de publication vous permet d'appliquer un correctif sans avoir à vous désabonner d'un canal. Cela vous permet de sécuriser vos nœuds jusqu'à ce que la nouvelle version devienne la version par défaut de votre canal de publication.

Moyen

Clusters Anthos sur VMware

Mise à jour : 22-04-2022

Description Gravité

Une faille de sécurité, CVE-2022-23648, a été détectée dans la gestion du balayage de chemin d'accès de containerd dans la spécification du volume d'images OCI. Les conteneurs lancés via l'implémentation CRI de containerd avec une configuration d'image spécialement conçue à cet effet peuvent bénéficier d'un accès en lecture complet aux fichiers et répertoires arbitraires de l'hôte.

Cette faille peut contourner toute application basée sur des règles lors de la configuration du conteneur (y compris une stratégie de sécurité des pods Kubernetes). Cette faille affecte tous les clusters Anthos sur VMware sur lesquels Stackdriver est activé. Celui-ci utilise containerd. Les versions 1.8, 1.9 et 1.10 des clusters Anthos sur VMware sont affectées.

Que dois-je faire ?

Mise à jour du 22-04-2022 : les versions suivantes des clusters Anthos sur VMware contiennent du code qui corrige cette faille.

  • Version 1.9.5 ou ultérieure
  • Version 1.10.3 ou ultérieure
  • Version 1.11.0 ou ultérieure

Les versions suivantes des clusters Anthos sur VMware ont été mises à jour avec du code pour corriger cette faille. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions des clusters Anthos sur VMware suivantes :

  • Version 1.8.8 ou ultérieure
  • Version 1.9.5 ou ultérieure
  • Version 1.10.2 ou ultérieure

Cette faille CVE peut être atténuée en définissant IgnoreImageDefinedVolumes sur "true".

Moyen

Anthos clusters on AWS

Description Gravité

Une faille de sécurité, CVE-2022-23648, a été détectée dans la gestion du balayage de chemin d'accès de containerd dans la spécification du volume d'images OCI. Les conteneurs lancés via l'implémentation CRI de containerd avec une configuration d'image spécialement conçue à cet effet peuvent bénéficier d'un accès en lecture complet aux fichiers et répertoires arbitraires de l'hôte.

Cette faille peut contourner toute application basée sur des règles lors de la configuration du conteneur (y compris une stratégie de sécurité des pods Kubernetes). Toutes les versions des clusters Anthos sur AWS sont affectées.

Que dois-je faire ?

Les versions suivantes des clusters Anthos sur AWS ont été mises à jour avec du code pour corriger cette faille. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions des clusters Anthos sur AWS suivantes.

Clusters Anthos sur AWS (génération actuelle)
  • Version 1.22 : 1.22.8-gke.200
  • Version 1.21 : 1.21.11-gke.100
Anthos clusters on AWS (génération précédente)
  • Version 1.22 : 1.22.8-gke.300
  • Version 1.21 : 1.21.11-gke.100
  • Version 1.20 : 1.20.15-gke.2200

Cette faille CVE peut être atténuée en définissant IgnoreImageDefinedVolumes sur "true".

Moyen

Anthos sur Azure

Description Gravité

Une faille de sécurité, CVE-2022-23648, a été détectée dans la gestion du balayage de chemin d'accès de containerd dans la spécification du volume d'images OCI. Les conteneurs lancés via l'implémentation CRI de containerd avec une configuration d'image spécialement conçue à cet effet peuvent bénéficier d'un accès en lecture complet aux fichiers et répertoires arbitraires de l'hôte.

Cette faille peut contourner toute application basée sur des règles lors de la configuration du conteneur (y compris une stratégie de sécurité des pods Kubernetes). Toutes les versions d'Anthos on Azure sont affectées.

Que dois-je faire ?

Les versions suivantes d'Anthos on Azure ont été mises à jour avec du code pour corriger cette faille. Nous vous recommandons de mettre à jour vos nœuds comme suit :

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

Cette faille CVE peut être atténuée en définissant IgnoreImageDefinedVolumes sur "true".

Moyen

Anthos sur solution Bare Metal

Mise à jour : 22-04-2022

Description Gravité

Une faille de sécurité, CVE-2022-23648, a été détectée dans la gestion du balayage de chemin d'accès de containerd dans la spécification du volume d'images OCI. Les conteneurs lancés via l'implémentation CRI de containerd avec une configuration d'image spécialement conçue à cet effet peuvent bénéficier d'un accès en lecture complet aux fichiers et répertoires arbitraires de l'hôte.

Cette faille peut contourner toute application basée sur des règles lors de la configuration du conteneur (y compris une stratégie de sécurité des pods Kubernetes). Cette faille affecte l'ensemble des clusters Anthos sur solution Bare Metal qui utilisent containerd. Les versions 1.8, 1.9 et 1.10 des clusters Anthos sur solution Bare Metal sont affectées.

Que dois-je faire ?

Mise à jour du 22-04-2022 : les versions suivantes d'Anthos sur solution Bare Metal contiennent du code qui corrige cette faille.

  • Version 1.8.9 ou ultérieure
  • Version 1.9.6 ou ultérieure
  • Version 1.10.3 ou ultérieure
  • Version 1.11.0 ou ultérieure

Les versions suivantes des clusters Anthos sur solution Bare Metal ont été mises à jour avec du code pour corriger cette faille. Nous vous recommandons de mettre à niveau vos nœuds vers l'une des versions des clusters Anthos sur solution Bare Metal suivantes :

  • Version 1.8.8 ou ultérieure
  • Version 1.9.5 ou ultérieure
  • Version 1.10.2 ou ultérieure

Cette faille CVE peut être atténuée en définissant IgnoreImageDefinedVolumes sur "true".

Moyen

GCP-2022-012

Date de publication : 2022-04-07
Référence : CVE-2022-0847

GKE

Description Gravité

Une faille de sécurité, CVE-2022-0847, a été détectée dans les versions 5.8 et ultérieures du noyau Linux. Celle-ci peut potentiellement faire remonter les droits du conteneur à la racine. Cette faille affecte toutes les versions de pools de nœuds GKE v1.22 et ultérieures qui utilisent des images Container-Optimized OS (Container-Optimized OS 93 et versions ultérieures). Les pools de nœuds GKE qui utilisent le système d'exploitation Ubuntu ne sont pas affectés.

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 pour corriger cette faille. Pour des raisons de sécurité, même si la mise à niveau automatique des nœuds est activée, nous vous recommandons de mettre à niveau manuellement vos pools de nœuds vers l'une des versions de GKE suivantes :

  • 1.22.7-gke.1500 et versions ultérieures
  • 1.23.4-gke.1600 et versions ultérieures

Une fonctionnalité récente des canaux de publication vous permet d'appliquer une version de correctif d'autres canaux de publication sans avoir à vous désabonner d'un canal. Cela vous permet de sécuriser vos nœuds jusqu'à ce que la nouvelle version devienne la version par défaut de votre canal de publication.

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

La faille CVE-2022-0847 concerne l'option PIPE_BUF_FLAG_CAN_MERGE qui a été introduite dans la version 5.8 du noyau Linux. Dans cette faille, le membre "flags" de la nouvelle structure du tampon de pipeline ne disposait pas de l'initialisation appropriée dans le noyau Linux. Un pirate informatique disposant d'un accès non privilégié en local peut utiliser cette faille pour écrire sur des pages du cache de pages sauvegardé par des fichiers en lecture seule et élever ses privilèges.

De nouvelles versions de Container-Optimized OS qui résolvent ce problème ont été intégrées aux versions mises à jour des pools de nœuds de GKE.

Élevé

clusters Anthos sur VMware

Description Gravité

Une faille de sécurité, CVE-2022-0847, a été détectée dans les versions 5.8 et ultérieures du noyau Linux. Celle-ci peut potentiellement faire remonter les droits à la racine. Cette faille affecte les clusters Anthos sur VMware v1.10 pour les images Container-Optimized OS. Actuellement, les clusters Anthos sur VMware avec Ubuntu disposent de la version de noyau 5.4 et ne sont pas vulnérables à cette attaque.

Que dois-je faire ?

Les versions des images de nœud Linux pour les versions suivantes des clusters Anthos sur VMware ont été mises à jour avec du code pour corriger cette faille. Nous vous recommandons de mettre à niveau vos clusters d'administrateur et d'utilisateur vers la version suivante des clusters Anthos sur VMware :

  • 1.10.3

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

La faille CVE-2022-0847 concerne l'option PIPE_BUF_FLAG_CAN_MERGE qui a été introduite dans la version 5.8 du noyau Linux. Dans cette faille, le membre "flags" de la nouvelle structure du tampon de pipeline ne disposait pas de l'initialisation appropriée dans le noyau Linux. Un pirate informatique disposant d'un accès non privilégié en local peut utiliser cette faille pour écrire sur des pages du cache de pages sauvegardé par des fichiers en lecture seule et élever ses privilèges.

De nouvelles versions de Container-Optimized OS qui résolvent ce problème ont été intégrées aux versions mises à jour des clusters Anthos sur VMware.

Élevé

Anthos clusters on AWS

Description Gravité

Une faille de sécurité, CVE-2022-0847, a été détectée dans les versions 5.8 et ultérieures du noyau Linux. Celle-ci peut potentiellement faire remonter les droits à la racine.

Cette faille affecte les clusters gérés Anthos sur AWS v1.21 et les clusters exécutés sur les clusters Anthos sur AWS (génération précédente) v1.19, v1.20, v1.21 qui utilisent Ubuntu.

Que dois-je faire ?

Les versions des images de nœud Linux pour les versions suivantes des clusters Anthos sur VMware ont été mises à jour avec du code pour corriger cette faille.

Pour les clusters gérés Anthos sur AWS, nous vous recommandons de mettre à niveau vos clusters d'utilisateur et votre pool de nœuds vers l'une des versions suivantes :

  • 1.21.11-gke.100

Pour les clusters Anthos sur AWS, nous vous recommandons de mettre à niveau vos objets AWSManagementService, AWSCluster et AWSNodePool vers la version suivante :

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

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

La faille CVE-2022-0847 concerne l'option PIPE_BUF_FLAG_CAN_MERGE qui a été introduite dans la version 5.8 du noyau Linux. Dans cette faille, le membre "flags" de la nouvelle structure du tampon de pipeline ne disposait pas de l'initialisation appropriée dans le noyau Linux. Un pirate informatique disposant d'un accès non privilégié en local peut utiliser cette faille pour écrire sur des pages du cache de pages sauvegardé par des fichiers en lecture seule et élever ses privilèges.

Élevé

Anthos sur Azure

Description Gravité

Une faille de sécurité, CVE-2022-0847, a été détectée dans les versions 5.8 et ultérieures du noyau Linux. Celle-ci peut potentiellement faire remonter les droits à la racine. Cette faille affecte les clusters gérés Anthos on Azure v1.21 qui utilisent Ubuntu.

Que dois-je faire ?

Les versions des images de nœud Linux pour les versions suivantes de Anthos on Azure ont été mises à jour avec du code pour corriger cette faille. Nous vous recommandons de mettre à niveau vos clusters d'utilisateur et votre pool de nœuds vers la version suivante :

  • 1.21.11-gke.100

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

La faille CVE-2022-0847 concerne l'option PIPE_BUF_FLAG_CAN_MERGE qui a été introduite dans la version 5.8 du noyau Linux. Dans cette faille, le membre "flags" de la nouvelle structure du tampon de pipeline ne disposait pas de l'initialisation appropriée dans le noyau Linux. Un pirate informatique disposant d'un accès non privilégié en local peut utiliser cette faille pour écrire sur des pages du cache de pages sauvegardé par des fichiers en lecture seule et élever ses privilèges.

Élevé

Anthos sur solution Bare Metal

Description Gravité

Une faille de sécurité, CVE-2022-0847, a été détectée dans les versions 5.8 et ultérieures du noyau Linux. Celle-ci peut potentiellement faire remonter les droits à la racine.

Que dois-je faire ?

Aucune action n'est requise. Anthos sur solution Bare Metal n'est pas affecté par cette faille CVE, car il n'inclut pas Linux dans son package. Vous devez vous assurer que les images de nœuds que vous utilisez sont mises à jour vers les versions contenant le correctif de la faille CVE-2022-0847.

Élevé

GCP-2022-011

Date de publication : 22/03/2022
Dernière mise à jour : 11/08/2022

Mise à jour du 11/08/2022 : ajout d'informations sur les effets d'une mauvaise configuration SMT.

GKE

Description Gravité

Mise à jour du 11/08/2022 : ajout d'informations sur la configuration multithread (Simultaneous Multi-Threading) . SMT était destiné à être désactivé, mais il a été activé sur les versions répertoriées.

Si vous avez activé manuellement SMT pour un pool de nœuds en bac à sable, SMT restera activé manuellement, malgré ce problème.


Il existe une erreur de configuration avec le mode SMT (Simultaneous Multi-Threading), également appelé Hyper-Threading, sur les images GKE Sandbox. L'erreur de configuration laisse des nœuds potentiellement exposés à des attaques de versions secondaires, telles que l'échantillonnage des données microarchitecturales (pour en savoir plus, consultez la documentation de GKE Sandbox). Nous vous déconseillons d'utiliser les versions concernées suivantes :

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

Si vous avez activé manuellement le mode SMT pour un pool de nœuds, ce problème n'affecte pas vos nœuds de bac à sable.

Que dois-je faire ?

Mettez à niveau vos nœuds vers l'une des versions suivantes :

  • 1.22.6-gke.1500 et versions ultérieures
  • 1.23.3-gke.1100 et versions ultérieures

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

Par défaut, le mode SMT est désactivé sur les nœuds GKE Sandbox, ce qui permet de limiter les attaques sur les versions secondaires.

Moyen

GCP-2022-009

Date de publication : 01-03-2022
Dernière mise à jour : 15-03-2022

GKE

Description Gravité

Mise à jour du 15-03-2022 : ajout de guides de renforcement pour Anthos clusters on AWS (GKE sur AWS) et Anthos on Azure. Ajout d'une section sur la persistance avec les webhooks


Certains chemins inattendus permettant d'accéder à la VM de nœud sur les clusters GKE Autopilot auraient pu être utilisés pour une élévation des privilèges dans le cluster. Ces problèmes ont été corrigés et aucune autre action n'est requise. Ces correctifs permettent de résoudre les problèmes signalés via notre Vulnerability Reward Program.

Les utilisateurs de clusters GKE Standard et Anthos peuvent éventuellement appliquer une règle de renforcement similaire, comme décrit ci-dessous.

Détails techniques

Accès à l'hôte impliquant des exceptions aux règles pour certains outils tiers

Pour permettre à Google Cloud de proposer une gestion complète des nœuds et un contrat de niveau de service au niveau des pods, GKE Autopilot restreint certaines primitives Kubernetes à privilèges élevés afin d'empêcher les charges de travail d'obtenir un accès de bas niveau à la VM de nœud. Pour replacer ces éléments dans leur contexte : GKE Standard offre un accès complet au calcul sous-jacent, Autopilot présente un accès limité et Cloud Run ne présente aucun accès.

Autopilot assouplit certaines de ces restrictions pour une liste prédéfinie d'outils tiers afin de permettre aux clients d'exécuter ces outils sur Autopilot sans modification. En utilisant des droits permettant de créer des pods avec des montages de chemin d'accès à l'hôte, le chercheur a pu exécuter dans un pod un conteneur privilégié qui ressemblait à l'un de ces outils tiers figurant dans la liste d'autorisation, afin d'obtenir l'accès à l'hôte.

La capacité à planifier des pods de cette manière est normale sur GKE Standard, mais pas sur GKE Autopilot, car cela implique de contourner les restrictions d'accès à l'hôte servant à activer le contrat de niveau de service décrit précédemment.

Ce problème a été résolu en restreignant la spécification de la liste d'autorisation des outils tiers pour le pod.

Élévation des privilèges à partir de la racine sur un nœud

En plus de l'accès à l'hôte, les pods stackdriver-metadata-agent-cluster-level et metrics-server ont été identifiés comme étant très privilégiés. Après avoir obtenu un accès au nœud au niveau racine, ces services peuvent être utilisés pour obtenir davantage de contrôle sur le cluster.

Nous avons abandonné et supprimé stackdriver-metadata-agent pour GKE Standard et Autopilot. Ce composant est toujours utilisé sur Anthos clusters on VMware et Anthos sur solution Bare Metal.

Afin de renforcer la protection du système contre ce type d'attaque à l'avenir, nous appliquerons dans une version ultérieure une contrainte Autopilot empêchant les mises à jour du compte de service de divers objets dans l'espace de noms kube-system. Nous avons développé une règle Gatekeeper pour que vous puissiez appliquer une protection similaire aux clusters GKE Standard et Anthos afin d'empêcher l'automodification des charges de travail privilégiées. Cette règle est appliquée automatiquement aux clusters Autopilot. Pour obtenir des instructions, consultez les guides de renforcement suivants :


15-03-2022: persistance avec des webhooks en mutation

Les webhooks ont été utilisés dans le rapport pour établir une base privilégiée dans le cluster après compromis. Il s'agit d'éléments standards de l'API Kubernetes créés par les administrateurs de cluster. Ils ont été rendus visibles aux administrateurs lorsque Autopilot a ajouté la compatibilité avec les webhooks définis par le client.


Comptes de service avec privilèges dans l'espace de noms par défaut

Les outils d'application de la règle Autopilot autorisaient précédemment deux comptes de service dans l'espace de noms par défaut : csi-attacher et otelsvc afin d'accorder des droits spéciaux à ces comptes de service. Un pirate informatique disposant de droits élevés, y compris les autorisations permettant de créer des objets ClusterRoleBinding et ayant un accès autorisant la création de pods dans l'espace de noms par défaut, peut utiliser ces noms de compte de service pour accéder à ces droits supplémentaires. Ces services ont été déplacés sous l'espace de noms kube-system afin de leur faire bénéficier de la protection de la règle Autopilot existante. Les clusters GKE Standard et les clusters Anthos ne sont pas affectés.

Que dois-je faire ?

Les règles de tous les clusters GKE Autopilot ont été mises à jour pour supprimer l'accès involontaire à l'hôte et aucune autre action n'est requise.

Dans les semaines à venir, le renforcement de la stratégie sera appliqué à Autopilot pour fournir une protection secondaire. Aucune action n'est requise.

Les clusters GKE Standard et les clusters Anthos ne sont pas affectés, car les utilisateurs ont déjà accès à l'hôte. Afin de renforcer la sécurité du système, les clusters GKE Standard et les utilisateurs de clusters Anthos peuvent appliquer une protection similaire via une règle Gatekeeper qui empêche l'automodification des charges de travail privilégiées. Pour obtenir des instructions, consultez les guides de renforcement suivants :

Faible

GCP-2022-008

Date de publication : 23-02-2022
Mise à jour : 28-04-2022
Référence : 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

Description Gravité
Le projet Envoy a récemment découvert un ensemble de failles, CVE-2022-23606, CVE-2022-21655 et CVE-2021-43826., CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657 et CVE-2022-21656 pouvant avoir un impact sur les clusters GKE utilisant Anthos Service Mesh, Istio-on-GKE ou des déploiements Istio personnalisés.
Tous les problèmes répertoriés ci-dessous sont résolus dans la version 1.21.1 d'Envoy.
Informations techniques
Pour en savoir plus sur ces failles, cliquez ici.

Que dois-je faire ?

Les clusters GKE exécutant Anthos Service Mesh doivent être mis à jour vers une version compatible avec les failles ci-dessus.
  • Si vous utilisez Anthos Service Mesh 1.12, passez à la version 1.12.4-asm.0.
  • Si vous utilisez Anthos Service Mesh 1.11, passez à la version 1.11.7-asm.1.
  • Si vous utilisez Anthos Service Mesh 1.10, passez à la version 1.10.6-asm.1.
Si vous utilisez Anthos Service Mesh v1.9 ou une version antérieure, votre version est arrivée en fin de vie et n'est plus prise en charge. Ces correctifs CVE n'ont pas été rétroportés. Vous devez effectuer une mise à jour vers ASM 1.10 ou une version ultérieure.

Les clusters GKE exécutant Istio-on-GKE doivent être mis à jour vers une version compatible avec les failles ci-dessus.
  • Si vous utilisez Istio-on-GKE 1.6, passez à la version 1.6.14-gke.8.
  • Si vous utilisez Istio-on-GKE 1.4.11, passez à la version 1.4.11-gke.4.
  • Si vous utilisez Istio-on-GKE 1.4.10, passez à la version 1.4.10-gke.23.
  • Si vous utilisez GKE 1.22 ou une version ultérieure, veuillez utiliser Istio GKE 1.4.10. Sinon, utilisez Istio-on-GKE 1.4.11.

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

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, et CVE-2022-21656
Élevé

clusters Anthos sur VMware

Mise à jour : 28-04-2022

Description Gravité
Envoy a récemment publié plusieurs correctifs de failles de sécurité. Anthos clusters on VMware est affecté, car Envoy est utilisé avec metrics-server. Les CVE Envoy que nous corrigeons sont répertoriées ci-dessous. Nous mettrons à jour ce bulletin en y ajoutant des versions spécifiques lorsqu'elles seront disponibles :
  • CVE-2021-43824 (score CVSS 6.5, moyen) : déréférencement possible de pointeur NULL lorsque vous utilisez la correspondance safe_regex du filtre JWT.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez une expression régulière de filtre JWT.
  • CVE-2021-43825 (score CVSS 6.1, moyen) : disponible après l'utilisation gratuite lorsque les filtres de réponse augmentent les données de réponse et que l'augmentation des données dépasse les limites de la mémoire tampon en aval.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez un filtre de décompression.
  • CVE-2021-43826 (score CVSS 6.1, moyen) : vulnérabilité de type "use-after-free" lors de la tunnelisation TCP sur HTTP, en cas de déconnexion en aval lors de l'établissement de la connexion en amont.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez un filtre de tunnelisation.
  • CVE-2022-21654 (score CVSS 7.3, élevé) : la gestion incorrecte des configurations permet la réutilisation des sessions mTLS sans revalidation après la modification des paramètres de validation.
    Remarque : Tous les services ASM/Istio-on-GKE utilisant mTLS sont affectés par cette faille CVE.
  • CVE-2022-21655 (score CVSS 7.5, élevé) : traitement incorrect des redirections internes vers les routes avec une entrée de réponse directe.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez un filtre de réponse directe.
  • CVE-2022-23606 (score CVSS 4.4, moyen) : épuisement de la pile lorsqu'un cluster est supprimé via le service de détection de clusters.
    Remarque : Cette faille CVE affecte la version 1.11 et les versions ultérieures d'ASM. ASM 1.10 et Istio-on-GKE ne sont pas affectés par cette faille CVE.
  • CVE-2022-21657 (score CVSS 3.1, faible) : les version d'Envoy jusqu'à la version 1.20.1 contiennent une faille exploitable à distance en raison du contournement X.509 de l'utilisation étendue de la clé et des objectifs de confiance.
  • CVE-2022-21656 (Score CVSS 3.1, Faible) : les versions d'Envoy jusqu'à la version 1.20.1 contiennent une faille exploitable à distance en raison du contournement X.509 de la mise en correspondance "subjectAltName" (et nameConstraints).

Istio a récemment publié un correctif de faille de sécurité. Anthos sur VMware est affecté, car Istio est utilisé pour le trafic entrant. Les CVE Istio que nous corrigeons sont répertoriées ci-dessous. Nous mettrons à jour ce bulletin en y ajoutant des versions spécifiques lorsqu'elles seront disponibles :

CVE-2022-23635 (score CVSS 7.5, élevé) : Istiod plante en cas de réception de requêtes avec un en-tête `authorization` spécialement conçu.


Pour obtenir la description complète et les impacts des CVE ci-dessus, consultez les bulletins de sécurité.

Ajout 28-04-2022 : Que dois-je faire ?

Les versions suivantes des clusters Anthos sur VMware corrigent ces failles :

  • 1.9.5
  • 1.10.3
  • 1.11.0

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

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, et CVE-2022-21656
Élevé

Anthos sur solution Bare Metal

Description Gravité
Envoy a récemment publié plusieurs correctifs de failles de sécurité. Anthos sur solution Bare Metal est affecté, car Envoy est utilisé avec metrics-server. Les failles CVE d'Envoy dans les versions 1.10.3, 1.9.6 et 1.8.9 sont répertoriées ci-dessous :
  • CVE-2021-43824 (score CVSS 6.5, moyen) : déréférencement possible de pointeur NULL lorsque vous utilisez la correspondance safe_regex du filtre JWT.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez une expression régulière de filtre JWT.
  • CVE-2021-43825 (score CVSS 6.1, moyen) : disponible après l'utilisation gratuite lorsque les filtres de réponse augmentent les données de réponse et que l'augmentation des données dépasse les limites de la mémoire tampon en aval.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez un filtre de décompression.
  • CVE-2021-43826 (score CVSS 6.1, moyen) : vulnérabilité de type "use-after-free" lors de la tunnelisation TCP sur HTTP, en cas de déconnexion en aval lors de l'établissement de la connexion en amont.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez un filtre de tunnelisation.
  • CVE-2022-21654 (score CVSS 7.3, élevé) : la gestion incorrecte des configurations permet la réutilisation des sessions mTLS sans revalidation après la modification des paramètres de validation.
    Remarque : Tous les services ASM/Istio-on-GKE utilisant mTLS sont affectés par cette faille CVE.
  • CVE-2022-21655 (score CVSS 7.5, élevé) : traitement incorrect des redirections internes vers les routes avec une entrée de réponse directe.
    Remarque : Bien que ASM/Istio-on-GKE ne soient pas compatibles avec les filtres Envoy, vous pourriez être affecté si vous utilisez un filtre de réponse directe.
  • CVE-2022-23606 (score CVSS 4.4, moyen) : épuisement de la pile lorsqu'un cluster est supprimé via le service de détection de clusters.
    Remarque : Cette faille CVE affecte la version 1.11 et les versions ultérieures d'ASM. ASM 1.10 et Istio-on-GKE ne sont pas affectés par cette faille CVE.
  • CVE-2022-21657 (score CVSS 3.1, faible) : les version d'Envoy jusqu'à la version 1.20.1 contiennent une faille exploitable à distance en raison du contournement X.509 de l'utilisation étendue de la clé et des objectifs de confiance.
  • CVE-2022-21656 (Score CVSS 3.1, Faible) : les versions d'Envoy jusqu'à la version 1.20.1 contiennent une faille exploitable à distance en raison du contournement X.509 de la mise en correspondance "subjectAltName" (et nameConstraints).
Istio a récemment publié un correctif de faille de sécurité. Anthos sur solution Bare Metal est affecté, car Istio est utilisé pour le trafic entrant. Les failles CVE d'Istio dans les versions 1.10.3, 1.9.6 et 1.8.9 sont répertoriées ci-dessous :

  • CVE-2022-23635 (score CVSS 7.5, élevé) : Istiod plante en cas de réception de requêtes avec un en-tête `authorization` spécialement conçu.
    Remarque : Toutes les failles ASM/Istio-on-GKE sont affectées par cette faille CVE.

Pour obtenir la description complète et les impacts des CVE ci-dessus, consultez les bulletins de sécurité.

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

CVE-2022-23606, CVE-2022-21655, CVE-2021-43826, CVE-2021-43825, CVE-2021-43824, CVE-2022-21654, CVE-2022-21657, et CVE-2022-21656
Élevé

GCP-2022-006

Date de publication : 14/02/2022
Mise à jour : 16-05-2022
Mise à jour du 16/05/2022 : Ajout de la version 1.19.16-gke.7800 de GKE ou d'une version ultérieure à la liste des versions contenant du code pour corriger cette faille.
Mise à jour du 12/05/2022 : Versions de correctif mises à jour pour GKE, Anthos sur solution Bare Metal, Anthos clusters sur VMware et Anthos clusters on AWS. Correction d'un problème qui empêchait l'affichage du bulletin de sécurité pour les clusters Anthos sur AWS lors de son ajout le 23/02/2022.

GKE

Description Gravité

Une faille de sécurité, CVE-2022-0492, a été détectée dans la fonction cgroup_release_agent_write du noyau Linux. L'attaque utilise des espaces de noms utilisateur non privilégiés et, dans certaines circonstances, peut être exploitable pour l'interruption d'un conteneur.

Que dois-je faire ?

Mise à jour du 16/05/2022 : en plus des versions GKE mentionnées dans la mise à jour du 12/05/2022, la version GKE 1.19.16-gke.7800 ou ultérieure contient également du code qui résout ce problème.


Mise à jour du 12/05/2022 : le code des versions suivantes de GKE a été mis à jour pour corriger cette faille :

  • 1.20.15-gke.5600 (et versions ultérieures)
  • 1.21.11-gke.1500 (et versions ultérieures)
  • 1.22.8-gke.1800 (et versions ultérieures)
  • 1.23.5-gke.1800 (et versions ultérieures)

Mise à jour du 15-02-2022 : instruction gVisor corrigée.

Cette faille se trouve dans le champ cgroup_release_agent_write du noyau Linux dans la fonction kernel/cgroup/cgroup-v1.c et peut être utilisée pour l'interruption d'un conteneur. GKE n'est pas affecté grâce à la protection du profil AppArmor par défaut sur Ubuntu et COS. Toutefois, certains clients peuvent toujours être vulnérables s'ils ont assoupli les restrictions de sécurité des pods via la modification du champ securityContext du pod ou du conteneur, par exemple, en désactivant ou modifiant le profil AppArmor, ce qui n'est pas recommandé. Outre le profil AppArmor par défaut, ces fonctionnalités protègent également contre la faille :

  • GKE Autopilot n'est pas affecté en raison du profil seccomp par défaut.
  • Mise à jour du 15/02/2022 : gVisor (GKE Sandbox) n'est pas affecté, car gVisor n'autorise pas l'accès à l'appel système de la faille sur l'hôte.

Les correctifs seront disponibles dans une prochaine version. Ce bulletin sera mis à jour dès qu'ils seront disponibles.

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

CVE-2022-0492

Faible

Clusters Anthos sur

Description Gravité

Une faille de sécurité, CVE-2022-0492, a été détectée dans la fonction cgroup_release_agent_write du noyau Linux. L'attaque utilise des espaces de noms utilisateur non privilégiés et, dans certaines circonstances, peut être exploitable pour l'interruption d'un conteneur.

Que dois-je faire ?

Mise à jour du 12-05-2022 : le code des versions suivantes des clusters Anthos sur VMware a été mis à jour pour corriger cette faille.

COS
  • Version 1.8.8 ou ultérieure
  • Version 1.9.5 ou ultérieure
  • Version 1.10.2 ou ultérieure
  • Version 1.11.0 ou ultérieure
Ubuntu
  • Version 1.9.6 ou ultérieure
  • Version 1.10.3 ou ultérieure
  • Version 1.11.0 ou ultérieure

Cette faille se trouve dans le champ cgroup_release_agent_write du noyau Linux, dans la fonction kernel/cgroup/cgroup-v1.c et peut être utilisée pour l'interruption d'un conteneur. Les clusters Anthos sur VMware ne sont pas affectés grâce à la protection du profil AppArmor par défaut sur Ubuntu et COS. Toutefois, certains clients peuvent toujours être vulnérables s'ils ont assoupli les restrictions de sécurité des pods via la modification du champ securityContext du pod ou du conteneur, par exemple, en désactivant ou modifiant le profil AppArmor, ce qui n'est pas recommandé.

Les correctifs seront disponibles dans une prochaine version. Ce bulletin sera mis à jour dès qu'ils seront disponibles.

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

CVE-2022-0492

Faible

Anthos clusters on AWS

Description Gravité

Une faille de sécurité, CVE-2022-0492, a été détectée dans la fonction cgroup_release_agent_write du noyau Linux. L'attaque utilise des espaces de noms utilisateur non privilégiés et, dans certaines circonstances, peut être exploitable pour l'interruption d'un conteneur.

Que dois-je faire ?

Mise à jour du 12/05/2022 : le code des versions suivantes des clusters Anthos de génération actuelle et précédente a été mis à jour pour corriger cette faille :

Génération actuelle
  • 1.21.11-gke.1100
  • 1.22.8-gke.1300
Génération précédente
  • 1.22.8-gke.1300
  • 1.21.11-gke.1100
  • 1.20.15-gke.5200

Mise à jour du 23/02/2022 : ajout d'une note sur les clusters Anthos sur AWS.

Les clusters Anthos de génération précédente et actuelle ne sont pas affectés par la protection du profil AppArmor par défaut sur Ubuntu. Toutefois, certains clients peuvent toujours être vulnérables s'ils ont assoupli les restrictions de sécurité des pods via la modification du champ securityContext du pod ou du conteneur, par exemple, en désactivant ou modifiant le profil AppArmor, ce qui n'est pas recommandé.

Les correctifs seront disponibles dans une prochaine version. Ce bulletin sera mis à jour dès que des informations sont disponibles.

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

CVE-2022-0492

Faible

Anthos sur

Description Gravité

Une faille de sécurité, CVE-2022-0492, a été détectée dans la fonction cgroup_release_agent_write du noyau Linux. L'attaque utilise des espaces de noms utilisateur non privilégiés et, dans certaines circonstances, peut être exploitable pour l'interruption d'un conteneur.

Que dois-je faire ?

Mise à jour du 12/05/2022 : le code des versions suivantes d'Anthos on Azure a été mis à jour pour corriger cette faille :

  • 1.21.11-gke.1100
  • 1.22.8-gke.1300

Anthos on Azure n'est pas affecté grâce à la protection du profil AppArmor par défaut sur Ubuntu. Toutefois, certains clients peuvent toujours être vulnérables s'ils ont assoupli les restrictions de sécurité des pods via la modification du champ securityContext du pod ou du conteneur, par exemple, en désactivant ou modifiant le profil AppArmor, ce qui n'est pas recommandé.

Les correctifs seront disponibles dans une prochaine version. Ce bulletin sera mis à jour dès qu'ils seront disponibles.

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

CVE-2022-0492

Faible

GCP-2022-005

Date de publication : 11/02/2022
Dernière mise à jour : 15/02/2022
Référence : CVE-2021-43527

GKE

Description Gravité
Mise à jour du 15-02-2022 : certaines versions de GKE mentionnées dans le bulletin d'origine étaient combinées à d'autres correctifs et leurs numéros de version étaient incrémentés avant la publication. Les correctifs sont disponibles dans les versions GKE suivantes :
  • 1.20.15-gke.300
  • 1.21.9-gke.300
  • 1.22.6-gke.1000

Une faille de sécurité, CVE-2021-43527, a été détectée dans tout binaire lié aux versions vulnérables de libnss3 trouvées dans les versions NSS (Network Security Services) antérieures à la version 3.73 ou 3.68.1. Les applications utilisant NSS pour la validation du certificat ou d'autres fonctionnalités TLS, X.509, OCSP ou CRL peuvent être affectées, suivant la manière dont NSS est utilisé/configuré. La version installée des images GKE COS et Ubuntu est vulnérable et doit être corrigée.

La faille CVE-2021-43527 peut potentiellement avoir un impact important sur les applications utilisant le service NSS pour gérer les signatures encodées dans CMS, S/MIME, PKCS#7 ou PKCS#12. Les applications qui utilisent NSS pour la validation des certificats ou d'autres fonctionnalités TLS, X.509, OCSP ou CRL peuvent aussi être affectées. L'impact dépend de la manière dont NSS est utilisé/configuré.

GKE n'utilise libnss3 pour aucune API accessible sur Internet. L'impact est limité au code hôte exécuté en dehors des conteneurs et est donc faible, du fait de la conception minimale de Chrome OS. Le code GKE qui s'exécute à l'intérieur de conteneurs utilisant l'image de base golang distroless n'est pas affecté.

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 pour corriger ces failles. Mettez à jour votre plan de contrôle et vos nœuds vers l'une des versions GKE suivantes :

  • Version 1.18 à déterminer
  • 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
Utilisez-vous une version GKE antérieure à la version 1.18 ? Vous utilisez une version de GKE dont le contrat de niveau de service a expiré et vous devriez envisager de passer à l'une des versions compatibles.

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

CVE-2021-43527

Moyen

Clusters Anthos sur

Description Gravité

Une faille de sécurité, CVE-2021-43527, a été détectée dans tout binaire lié aux versions vulnérables de libnss3 trouvées dans les versions NSS (Network Security Services) antérieures à la version 3.73 ou 3.68.1. Les applications utilisant NSS pour la validation du certificat ou d'autres fonctionnalités TLS, X.509, OCSP ou CRL peuvent être affectées, selon leur configuration NSS. La version installée des images des clusters Anthos sur VMware COS et Ubuntu est vulnérables et doit être corrigée.

La faille CVE-2021-43527 peut potentiellement avoir un impact important sur les applications utilisant le service NSS pour gérer les signatures encodées dans CMS, S/MIME, PKCS \#7 ou PKCS \#12. Les applications qui utilisent NSS pour la validation des certificats ou d'autres fonctionnalités TLS, X.509, OCSP ou CRL peuvent aussi être affectées. L'impact dépend de la manière dont elles utilisent/configurent NSS. Anthos sur VMware n'utilise libnss3 pour aucune des API accessibles au public. Par conséquent, l'impact est limité et le niveau de gravité de cette faille CVE pour Anthos clusters on VMware est classé comme "Moyen".

Que dois-je faire ?

Les versions des images de nœuds Linux pour les versions suivantes d'Anthos ont été mises à jour avec du code pour corriger cette faille. Mettez à niveau votre plan de contrôle et vos nœuds vers l'une des versions d'Anthos suivantes :

  • 1.8.7
  • 1.9.4
  • 1.10.2

Utilisez-vous un cluster Anthos sur VMware antérieur à la version 1.18 ? Vous utilisez une version d'Anthos dont le contrat de niveau de service a expiré et vous devriez envisager de passer à l'une des versions compatibles.

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

CVE-2021-43527

Moyen

Anthos sur

Description Gravité

Une faille de sécurité, CVE-2021-43527, a été détectée dans tout binaire lié aux versions vulnérables de libnss3 trouvées dans les versions NSS (Network Security Services) antérieures à la version 3.73 ou 3.68.1. Les applications utilisant NSS pour la validation du certificat ou d'autres fonctionnalités TLS, X.509, OCSP ou CRL peuvent être affectées, suivant la manière dont NSS est utilisé/configuré. La version installée des images Ubuntu Anthos clusters on Azure est vulnérable et doit être corrigée.

La faille CVE-2021-43527 peut potentiellement avoir un impact important sur les applications utilisant le service NSS pour gérer les signatures encodées dans CMS, S/MIME, PKCS#7 ou PKCS#12. Les applications qui utilisent NSS pour la validation des certificats ou d'autres fonctionnalités TLS, X.509, OCSP ou CRL peuvent aussi être affectées. L'impact dépend de la manière dont elles utilisent/configurent NSS. Anthos clusters on Azure n'utilise libnss3 pour aucune des API accessibles au public. Par conséquent, l'impact est limité et le niveau de gravité de cette faille CVE pour Anthos clusters on Azure est classé comme "Moyen".

Que dois-je faire ?

Les versions des images de nœud Linux pour les versions suivantes de Anthos on Azure ont été mises à jour avec du code pour corriger ces failles. Mettez à niveau vos clusters vers l'une des versions d'Anthos on Azure suivantes :

  • v1.21.6-gke.1500

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

CVE-2021-43527

Moyen

GCP-2022-004

Date de publication : 2022-02-04
Référence : CVE-2021-4034

GKE

Description Gravité

Une faille de sécurité, CVE-2021-4034, a été détectée dans pkexec, une partie du package du kit de règles Linux (polkit), qui permet à un utilisateur authentifié d'effectuer une attaque d'élévation des privilèges. PolicyKit n'est généralement utilisé que sur les systèmes de bureau Linux pour permettre aux utilisateurs non racines d'effectuer des actions telles que le redémarrage du système, l'installation de packages ou le redémarrage de services conformément à une règle.

Que dois-je faire ?

GKE n'est pas affecté, car le module vulnérable, policykit-1, n'est pas installé sur les images COS ou Ubuntu utilisées dans GKE. Aucune action n'est requise.

None

Clusters Anthos sur

Description Gravité

Une faille de sécurité, CVE-2021-4034, a été détectée dans pkexec, une partie du package du kit de règles Linux (polkit), qui permet à un utilisateur authentifié d'effectuer une attaque d'élévation des privilèges. PolicyKit n'est généralement utilisé que sur les systèmes de bureau Linux pour permettre aux utilisateurs non racines d'effectuer des actions telles que le redémarrage du système, l'installation de packages ou le redémarrage de services conformément à une règle.

La configuration par défaut d'Anthos confère déjà aux utilisateurs des privilèges "sudo" complets. Par conséquent, cette attaque ne modifie pas la stratégie de sécurité existante d'Anthos.

Détails techniques

Pour que ce bug soit exploitable, un pirate informatique doit disposer d'une interface système non racine sur le système de fichiers de nœud et avoir installé la version vulnérable de pkexec. Même si les clusters Anthos sur VMware incluent une version de policykit-1 dans ses versions d'image, la configuration par défaut d'Anthos autorise les fonctionnalités sudo sans mot de passe à tout utilisateur ayant déjà accès à l'interface système. Par conséquent, cette faille n'accorde pas plus de privilèges.

Que dois-je faire ?

Aucune action n'est requise. Les clusters Anthos sur VMware ne sont pas affectés.

None

Clusters Anthos sur

Description Gravité
Les clusters Anthos sur AWS ne sont pas affectés. Le module vulnérable, Policykit-1, n'est pas installé sur les images Ubuntu utilisées par les versions actuelles et précédentes des clusters Anthos sur AWS. None

Anthos sur

Description Gravité

Une faille de sécurité, CVE-2021-4034, a été détectée dans pkexec, une partie du package du kit de règles Linux (polkit), qui permet à un utilisateur authentifié d'effectuer une attaque d'élévation des privilèges. PolicyKit n'est généralement utilisé que sur les systèmes de bureau Linux pour permettre aux utilisateurs non racines d'effectuer des actions telles que le redémarrage du système, l'installation de packages ou le redémarrage de services conformément à une règle.

La configuration par défaut d'Anthos confère déjà aux utilisateurs des privilèges "sudo" complets. Par conséquent, cette attaque ne modifie pas la stratégie de sécurité existante d'Anthos.

Détails techniques

Pour que ce bug soit exploitable, un pirate informatique doit disposer d'une interface système non racine sur le système de fichiers de nœud et avoir installé la version vulnérable de pkexec. Même si Anthos on Azure inclut une version de policykit-1 dans ses versions d'image, la configuration par défaut d'Anthos autorise les fonctionnalités sudo sans mot de passe à tout utilisateur ayant déjà accès à l'interface système. Par conséquent, cette faille n'accorde pas plus de privilèges.

Que dois-je faire ?

Aucune action n'est requise. Anthos on Azure n'est pas affecté.

None

Clusters Anthos sur

Description Gravité
L'utilisation d'Anthos sur solution Bare Metal peut être affectée suivant les packages installés sur le système d'exploitation géré par le client. Analysez vos images d'OS et appliquez-leur les correctifs si nécessaire. None

GCP-2022-002

Publié : 01/02/2022
Mis à jour : 07/03/2022
Référence :
CVE-2021-4154, CVE-2021-22600, CVE-2022-0185
Mise à jour du 04/02/2022 : ajout des sections concernant les clusters Anthos sur AWS et Anthos on Azure. Ajout de mises à jour de déploiement pour les clusters GKE et Anthos sur VMware.

GKE

Mis à jour : 07/03/2022

Description Gravité

Trois failles de sécurité : CVE-2021-4154, CVE-2021-22600 et CVE-2022-0185 ont été découvertes dans le noyau Linux, chacune pouvant entraîner une rupture de conteneur, une élévation des privilèges sur l'hôte ou les deux. Ces failles affectent tous les systèmes d'exploitation de nœud (COS et Ubuntu) sur GKE, les clusters Anthos sur VMware, les clusters Anthos sur AWS (génération actuelle et précédente) et Anthos on Azure.

Les pods utilisant GKE Sandbox ne sont pas vulnérables à ces failles.

Pour en savoir plus, consultez la page Notes de version COS.

Détails techniques

Dans la faille CVE-2021-4154, un pirate informatique peut exploiter le paramètre d'appel du système fsconfig pour déclencher un bug "use-after-free" dans le noyau Linux, ce qui entraîne l'obtention de privilèges racine. Il s'agit d'une attaque par élévation des privilèges locaux qui entraîne une interruption du conteneur.

La faille CVE-2021-22600 est une attaque "double-free" dans paquet_set_ring qui peut entraîner l'échappement du conteneur vers le nœud hôte.

Avec la faille CVE-2022-0185, un bug de dépassement du tas de mémoire dans Legacy_parse_param() peut produire une écriture hors limites qui entraînera une interruption du conteneur.

Le chemin d'exploitation de cette faille qui repose sur l'appel système "unshare" est bloqué par défaut sur les clusters GKE Autopilot à l'aide du filtrage seccomp.

Les utilisateurs qui ont activé manuellement le profil seccomp de l'environnement d'exécution du conteneur par défaut sur les clusters GKE standards sont également protégés.

Que dois-je faire ?

Mise à jour du 07/03/2022 : les versions des images de nœuds Linux pour les versions suivantes de GKE ont été mises à jour avec du code afin de corriger toutes ces failles pour les images Ubuntu et COS. Mettez à niveau votre plan de contrôle et vos nœuds vers l'une des versions GKE suivantes :

  • 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

Mise à jour du 25-02-2022 : si vous utilisez des images de nœuds Ubuntu, 1.22.6-gke.1000 ne traite pas la faille CVE-2021-22600. Nous mettrons à jour ce bulletin en y ajoutant les versions de correctif Ubuntu lorsqu'elles seront disponibles.


Mise à jour du 23-02-2022 : les versions des images de nœuds Linux pour les versions suivantes de GKE ont été mises à jour avec du code afin de corriger ces failles. Mettez à niveau vos clusters vers l'une des versions suivantes.

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

Mise à jour du 04-02-2022 : la date de début du déploiement des versions de correctif de GKE était le 2 février.


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

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

es versions 1.22 et 1.23 sont également en cours. Nous mettrons à jour ce bulletin en y ajoutant des versions spécifiques lorsqu'elles seront disponibles.

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

Élevé

Clusters Anthos sur

Dernière mise à jour : 23-02-2022

Description Gravité

Trois failles de sécurité : CVE-2021-4154, CVE-2021-22600 et CVE-2022-0185 ont été découvertes dans le noyau Linux, chacune pouvant entraîner une rupture de conteneur, une élévation des privilèges sur l'hôte ou les deux. Ces failles affectent tous les systèmes d'exploitation de nœud (COS et Ubuntu) sur GKE, les clusters Anthos sur VMware, les clusters Anthos sur AWS (génération actuelle et précédente) et Anthos on Azure.

Pour en savoir plus, consultez la page Notes de version COS.

Détails techniques

Dans la faille CVE-2021-4154, un pirate informatique peut exploiter le paramètre d'appel du système fsconfig pour déclencher un bug "use-after-free" dans le noyau Linux, ce qui entraîne l'obtention de privilèges racine. Il s'agit d'une attaque par élévation des privilèges locaux qui entraîne une interruption du conteneur.

La faille CVE-2021-22600 est une attaque "double-free" dans paquet_set_ring qui peut entraîner l'échappement du conteneur vers le nœud hôte.

Avec la faille CVE-2022-0185, un bug de dépassement du tas de mémoire dans Legacy_parse_param() peut produire une écriture hors limites qui entraînera une interruption du conteneur.

Les utilisateurs qui ont activé manuellement le profil seccomp de l'environnement d'exécution du conteneur par défaut sur les clusters GKE standards sont également protégés.

Que dois-je faire ?

Mise à jour du 23-02-2022 : la version 1.10.2 (correctifs CVE-2021-22600, CVE-2021-4154 et CVE-2022-0185) est désormais prévue pour le 1er mars.

Mise à jour du 23-02-2022 : ajout de versions corrigées qui traitent la faille CVE-2021-2260.

La version 1.10.1 ne résout pas les problèmes liés à la faille CVE-2021-22600, mais traite les autres failles. Les versions 1.9.4 et 1.10.2, non publiées, résoudront la faille CVE-2021-22600. Les versions des images de nœud Linux pour les versions suivantes des clusters Anthos sur VMware ont été mises à jour avec du code pour corriger ces failles. Mettez à niveau vos clusters vers l'une des versions suivantes des clusters Anthos sur VMware :

  • 1.10.1 (correctifs CVE-2021-4154 et CVE-2022-0185. Publiés le 10 février)
  • 1.8.7 (Correctifs CVE-2021-22600, CVE-2021-4154 et CVE-2022-0185. Publiés le 17 février)
  • 1.9.4 (Correctifs CVE-2021-22600, CVE-2021-4154 et CVE-2022-0185. Publiés le 23 février)
  • 1.10.2 (Correctifs CVE-2021-22600, CVE-2021-4154 et CVE-2022-0185. Programmés pour le 24 février)

Mise à jour du 04-02-2022 : ajout d'informations sur les images Ubuntu qui ne traitent pas la faille CVE-2021-22600.

Les versions des images de nœud Linux pour les versions suivantes de Anthos Clusters on VMware ont été mises à jour avec du code pour corriger ces failles. Mettez à niveau vos clusters vers l'une des versions suivantes de Anthos clusters on VMware :

  • 1.10.1 (mise à jour COS uniquement Le correctif Ubuntu sera présent dans la version 1.10.2-23 programmée le 23 février.
  • 1.9.4 (programmée le 15 février)
  • 1.8.7 (programmée le 15 février)

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

Élevé

Clusters Anthos sur

Description Gravité

Trois failles de sécurité : CVE-2021-4154, CVE-2021-22600 et CVE-2022-0185 ont été découvertes dans le noyau Linux, chacune pouvant entraîner une rupture de conteneur, une élévation des privilèges sur l'hôte ou les deux. Ces failles affectent tous les systèmes d'exploitation de nœud (COS et Ubuntu) sur GKE, les clusters Anthos sur VMware, les clusters Anthos sur AWS (génération actuelle et précédente) et Anthos on Azure.

Pour en savoir plus, consultez la page Notes de version COS.

Détails techniques

Dans la faille CVE-2021-4154, un pirate informatique peut exploiter le paramètre d'appel du système fsconfig pour déclencher un bug "use-after-free" dans le noyau Linux, ce qui entraîne l'obtention de privilèges racine. Il s'agit d'une attaque par élévation des privilèges locaux qui entraîne une interruption du conteneur.

La faille CVE-2021-22600 est une attaque "double-free" dans paquet_set_ring qui peut entraîner l'échappement du conteneur vers le nœud hôte.

Avec la faille CVE-2022-0185, un bug de dépassement du tas de mémoire dans Legacy_parse_param() peut produire une écriture hors limites qui entraînera une interruption du conteneur.

Les utilisateurs qui ont activé manuellement le profil seccomp de l'environnement d'exécution du conteneur par défaut sur les clusters GKE standards sont également protégés.

Que dois-je faire ?

Anthos clusters on AWS

Les versions des images de nœud Linux pour les versions suivantes des clusters Anthos sur VMware ont été mises à jour avec du code pour corriger ces failles. Mettez à niveau vos clusters vers les versions suivantes des clusters Anthos sur AWS :

  • 1.21.6-gke.1500 et versions ultérieures (disponible en février)

Anthos clusters on AWS (génération précédente)

Les versions des images de nœud Linux pour les versions suivantes des clusters Anthos sur AWS (génération précédente) ont été mises à jour avec du code pour corriger ces failles. Mettez à niveau vos clusters vers l'une des versions des clusters Anthos sur AWS suivantes (génération précédente) :

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

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

Élevé

Anthos sur

Description Gravité

Trois failles de sécurité : CVE-2021-4154, CVE-2021-22600 et CVE-2022-0185 ont été découvertes dans le noyau Linux, chacune pouvant entraîner une rupture de conteneur, une élévation des privilèges sur l'hôte ou les deux. Ces failles affectent tous les systèmes d'exploitation de nœud (COS et Ubuntu) sur GKE, les clusters Anthos sur VMware, les clusters Anthos sur AWS (génération actuelle et précédente) et Anthos on Azure.

Pour en savoir plus, consultez la page Notes de version COS.

Détails techniques

Dans la faille CVE-2021-4154, un pirate informatique peut exploiter le paramètre d'appel du système fsconfig pour déclencher un bug "use-after-free" dans le noyau Linux, ce qui entraîne l'obtention de privilèges racine. Il s'agit d'une attaque par élévation des privilèges locaux qui entraîne une interruption du conteneur.

La faille CVE-2021-22600 est une attaque "double-free" dans paquet_set_ring qui peut entraîner l'échappement du conteneur vers le nœud hôte.

Avec la faille CVE-2022-0185, un bug de dépassement du tas de mémoire dans Legacy_parse_param() peut produire une écriture hors limites qui entraînera une interruption du conteneur.

Les utilisateurs qui ont activé manuellement le profil seccomp de l'environnement d'exécution du conteneur par défaut sur les clusters GKE standards sont également protégés.

Que dois-je faire ?

Les versions des images de nœud Linux pour les versions suivantes de Anthos on Azure ont été mises à jour avec du code pour corriger ces failles. Mettez à niveau vos clusters vers la version suivante d'Anthos on Azure :

  • 1.21.6-gke.1500 et versions ultérieures (disponible en février)

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

Élevé

GCP-2021-024

Date de publication : 21/10/2021
Référence : CVE-2021-25742

GKE

Description Gravité

Un problème de sécurité a été détecté dans le contrôleur Kubernetes ingress-nginx, CVE-2021-25742. Les extraits personnalisés ingress-nginx permettent la récupération des jetons de compte de service ingress-nginx et des secrets sur tous les espaces de noms.

Que dois-je faire ?

Ce problème de sécurité n'a aucune incidence sur votre infrastructure de cluster GKE, ni sur une infrastructure de cluster d'environnement Anthos. Si vous utilisez ingress-nginx lors de vos déploiements de charges de travail, vous devez avoir connaissance de ce problème de sécurité. Pour en savoir plus, consultez la page Problème ingress-nginx 7837.

Aucun

Clusters Anthos sur

Description Gravité

Un problème de sécurité a été détecté dans le contrôleur Kubernetes ingress-nginx, CVE-2021-25742. Les extraits personnalisés ingress-nginx permettent la récupération des jetons de compte de service ingress-nginx et des secrets sur tous les espaces de noms.

Que dois-je faire ?

Ce problème de sécurité n'a aucune incidence sur votre infrastructure de cluster GKE, ni sur une infrastructure de cluster d'environnement Anthos. Si vous utilisez ingress-nginx lors de vos déploiements de charges de travail, vous devez avoir connaissance de ce problème de sécurité. Pour en savoir plus, consultez la page Problème ingress-nginx 7837.

Aucun

Clusters Anthos sur

Description Gravité

Un problème de sécurité a été détecté dans le contrôleur Kubernetes ingress-nginx, CVE-2021-25742. Les extraits personnalisés ingress-nginx permettent la récupération des jetons de compte de service ingress-nginx et des secrets sur tous les espaces de noms.

Que dois-je faire ?

Ce problème de sécurité n'a aucune incidence sur votre infrastructure de cluster GKE, ni sur une infrastructure de cluster d'environnement Anthos. Si vous utilisez ingress-nginx lors de vos déploiements de charges de travail, vous devez avoir connaissance de ce problème de sécurité. Pour en savoir plus, consultez la page Problème ingress-nginx 7837.

Aucun

Clusters Anthos sur

Description Gravité

Un problème de sécurité a été détecté dans le contrôleur Kubernetes ingress-nginx, CVE-2021-25742. Les extraits personnalisés ingress-nginx permettent la récupération des jetons de compte de service ingress-nginx et des secrets sur tous les espaces de noms.

Que dois-je faire ?

Ce problème de sécurité n'a aucune incidence sur votre infrastructure de cluster GKE, ni sur une infrastructure de cluster d'environnement Anthos. Si vous utilisez ingress-nginx lors de vos déploiements de charges de travail, vous devez avoir connaissance de ce problème de sécurité. Pour en savoir plus, consultez la page Problème ingress-nginx 7837.

Aucun

GCP-2021-019

Publié : 2021-09-29

GKE

Description Gravité

Il existe un problème connu lorsque la mise à jour d'une ressource BackendConfig à l'aide de l'API v1beta1 supprime des règles de sécurité Google Cloud Armor actives de son service.

Suis-je concerné ?

Si votre BackendConfig a déjà été mise à jour avec l'API v1beta1, votre stratégie de sécurité Google Cloud Armor a peut-être été supprimée. Pour déterminer si c'est le cas, exécutez la commande suivante :


kubectl get backendconfigs -A -o json | \
jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'
  • Si la réponse renvoie des résultats : votre cluster est affecté par le problème. Le résultat de cette commande renvoie la liste des ressources BackendConfig (<namespace>/<name>) concernées par le problème.
  • Si le résultat est vide : cela signifie que votre BackendConfig n'a pas été mise à jour à l'aide de l'API v1beta1 depuis l'apparition du problème. Une mise à jour ultérieure de votre BackendConfig ne doit utiliser que la version v1.

Ce problème affecte les versions GKE suivantes :

  • 1.18.19-gke.1400 à 1.18.20-gke.5100 (exclusive)
  • 1.19.10-gke.700 à 1.19.14-gke.300 (exclusive)
  • 1.20.6-gke.700 à 1.20.9-gke.900 (exclusive)
  • 1.21 à 1.21.1-gke.2700 (exclusive)

Si vous ne configurez pas Google Cloud Armor sur vos ressources Ingress via une ressource BackendConfig, ce problème n'affecte pas vos clusters.

Que dois-je faire ?

Mettez à niveau votre plan de contrôle GKE vers l'une des versions mises à jour suivantes, qui corrigent ce problème et permettent d'utiliser les ressources v1beta1 BackendConfig en toute sécurité :

  • 1.21.1-gke.2700 et versions ultérieures
  • 1.20.9-gke.900 et versions ultérieures
  • 1.19.14-gke.300 et versions ultérieures
  • 1.18.20-gke.5100 et versions ultérieures

Ce problème peut également être évité en évitant le déploiement des ressources BackendConfig v1beta1. Si vous configurez Google Cloud Armor sur vos ressources Ingress via BackendConfig et que vous avez constaté que vous êtes concerné par les étapes ci-dessus, réactivez Google Cloud Armor en mettant à jour à votre ressource BackendConfig actuelle à la version d'API cloud.google.com/v1.

Pour éviter ce problème, mettez à jour uniquement votre fichier BackendConfig à l'aide de l'API BackendConfig v1.

Comme BackendConfig v1 accepte les mêmes champs que v1beta1 et n'apporte aucune modification, le champ d'API peut être mis à jour de manière transparente. Pour ce faire, remplacez le champ apiVersion de tout fichier manifeste BackendConfig actif par cloud.google.com/v1 et n'utilisez pas cloud.google.com/v1beta1.

L'exemple de fichier manifeste suivant décrit une ressource BackendConfig qui utilise l'API v1 :


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

Si vous disposez de systèmes ou d'outils CI/CD qui mettent régulièrement à jour des ressources BackendConfig, assurez-vous d'utiliser le groupe d'API cloud.google.com/v1 dans ces systèmes.

Faible

GCP-2021-022

Publié : 2021-09-23

Clusters Anthos sur

Description Gravité

Une faille a été détectée dans le module LDAP Anthos Identity Service (AIS) des versions 1.8 et 1.8.1 d'Anthos Clusters on VMware, où une clé initiale utilisée dans la génération de clés est prévisible. Avec cette faille, un utilisateur authentifié peut ajouter des revendications arbitraires et élever les privilèges indéfiniment.

Détails techniques

Un ajout récent au code AIS crée des clés symétriques à l'aide du module math/rand de golang, qui n'est pas adapté au code sensible à la sécurité. Le module est utilisé de manière à générer une clé prévisible. Lors de la vérification de l'identité, une clé STS (Secure Token Service) est générée. Elle est ensuite chiffrée par une clé symétrique simple à obtenir.

Que dois-je faire ?

Cette faille affecte uniquement les clients utilisant AIS dans les versions 1.8 et 1.8.1 d'Anthos Clusters on VMware. Pour les utilisateurs d'Anthos Clusters on VMware 1.8, mettez à niveau vos clusters vers la version suivante :

  • 1.8.2
Élevé

GCP-2021-021

Date de publication : 2021-09-22
Référence : CVE-2020-8561

GKE

Description Gravité

Une faille de sécurité, CVE-2020-8561, a été détectée dans Kubernetes. Certains webhooks peuvent être effectués pour rediriger les requêtes kube-apiserver vers des réseaux privés de cette API.

Détails techniques

Avec cette faille, les individus qui contrôlent les réponses des requêtes MutatingWebhookConfiguration ou ValidatingWebhookConfiguration peuvent rediriger les requêtes kube-apiserver vers les réseaux privés du serveur d'API. Si cet utilisateur peut afficher les journaux kube-apiserver lorsque le niveau de journalisation est défini sur 10, il peut afficher les réponses et les en-têtes redirigés dans les journaux.

Ce problème peut être atténué en modifiant certains paramètres du serveur d'API.

Que dois-je faire ?

Aucune action de votre part n'est nécessaire pour l'instant.

Les versions actuellement disponibles de GKE et Anthos ont mis en œuvre les mesures d'atténuation suivantes qui vous protègent contre ce type d'attaque :

  • L'option --profiling de kube-apiserver est définie sur false.
  • Le niveau de journalisation kube-apiserver est défini en dessous de 10.

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

CVE-2020-8561

Moyen

Clusters Anthos sur

Description Gravité

Une faille de sécurité, CVE-2020-8561, a été détectée dans Kubernetes. Certains webhooks peuvent être effectués pour rediriger les requêtes kube-apiserver vers des réseaux privés de cette API.

Détails techniques

Avec cette faille, les individus qui contrôlent les réponses des requêtes MutatingWebhookConfiguration ou ValidatingWebhookConfiguration peuvent rediriger les requêtes kube-apiserver vers les réseaux privés du serveur d'API. Si cet utilisateur peut afficher les journaux kube-apiserver lorsque le niveau de journalisation est défini sur 10, il peut afficher les réponses et les en-têtes redirigés dans les journaux.

Ce problème peut être atténué en modifiant certains paramètres du serveur d'API.

Que dois-je faire ?

Aucune action de votre part n'est nécessaire pour l'instant.

Les versions actuellement disponibles de GKE et Anthos ont mis en œuvre les mesures d'atténuation suivantes qui vous protègent contre ce type d'attaque :

  • L'option --profiling de kube-apiserver est définie sur false.
  • Le niveau de journalisation kube-apiserver est défini en dessous de 10.

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

CVE-2020-8561

Moyen

Clusters Anthos sur

Description Gravité

Une faille de sécurité, CVE-2020-8561, a été détectée dans Kubernetes. Certains webhooks peuvent être effectués pour rediriger les requêtes kube-apiserver vers des réseaux privés de cette API.

Détails techniques

Avec cette faille, les individus qui contrôlent les réponses des requêtes MutatingWebhookConfiguration ou ValidatingWebhookConfiguration peuvent rediriger les requêtes kube-apiserver vers les réseaux privés du serveur d'API. Si cet utilisateur peut afficher les journaux kube-apiserver lorsque le niveau de journalisation est défini sur 10, il peut afficher les réponses et les en-têtes redirigés dans les journaux.

Ce problème peut être atténué en modifiant certains paramètres du serveur d'API.

Que dois-je faire ?

Aucune action de votre part n'est nécessaire pour l'instant.

Les versions actuellement disponibles de GKE et Anthos ont mis en œuvre les mesures d'atténuation suivantes qui vous protègent contre ce type d'attaque :

  • L'option --profiling de kube-apiserver est définie sur false.
  • Le niveau de journalisation kube-apiserver est défini en dessous de 10.

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

CVE-2020-8561

Moyen

Clusters Anthos sur

Description Gravité

Une faille de sécurité, CVE-2020-8561, a été détectée dans Kubernetes. Certains webhooks peuvent être effectués pour rediriger les requêtes kube-apiserver vers des réseaux privés de cette API.

Détails techniques

Avec cette faille, les individus qui contrôlent les réponses des requêtes MutatingWebhookConfiguration ou ValidatingWebhookConfiguration peuvent rediriger les requêtes kube-apiserver vers les réseaux privés du serveur d'API. Si cet utilisateur peut afficher les journaux kube-apiserver lorsque le niveau de journalisation est défini sur 10, il peut afficher les réponses et les en-têtes redirigés dans les journaux.

Ce problème peut être atténué en modifiant certains paramètres du serveur d'API.

Que dois-je faire ?

Aucune action de votre part n'est nécessaire pour l'instant.

Les versions actuellement disponibles de GKE et Anthos ont mis en œuvre les mesures d'atténuation suivantes qui vous protègent contre ce type d'attaque :

  • L'option --profiling de kube-apiserver est définie sur false.
  • Le niveau de journalisation kube-apiserver est défini en dessous de 10.

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

CVE-2020-8561

Moyen

GCP-2021-018

Date de publication : 15/09/2021
Dernière mise à jour : 24/09/2021
Référence : CVE-2021-25741

Mise à jour du 24/09/2021 : bulletin d'Anthos sur solution Bare Metal mis à jour avec des versions corrigées supplémentaires.

Mise à jour du 20/09/2021 : bulletins ajoutés pour les clusters Anthos sur solution Bare Metal

Mise à jour du 16/09/2021 : bulletins ajoutés pour les clusters Anthos on VMware


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 ?

Nous vous recommandons de mettre à niveau vos pools de nœuds vers l'une des versions suivantes ou ultérieure, afin de bénéficier des derniers correctifs :

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

Les versions suivantes contiennent également le correctif :

  • 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
É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 ?

Mis à jour du 24/09/2021 : les versions 1.8.3 et 1.7.4 corrigées sont désormais disponibles.

Mise à jour du 17/09/2021 : correction de la liste des versions disponibles contenant le correctif.


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

  • 1.8.3
  • 1.8.2
  • 1.7.4
  • 1.6.5
É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 ?

Mise à jour du 16-9-2021 : ajout d'une liste des versions gke-versions compatibles pour les objets AWSCluster et AWSNodePool.


Les versions suivantes des clusters Anthos on AWS ont été mises à jour avec du code pour corriger cette faille. Voici nos recommandations :

  • Mettez à jour vos objets AWSManagementService, AWSCluster et AWSNodePool vers la version suivante :
    • 1.8.2
  • Mettez à jour la version gke-version de vos objets AWSCluster et AWSNodePool vers l'une des versions Kubernetes compatibles :
    • 1.17.17-gke.15800
    • 1.18.20-gke.4800
    • 1.19.14-gke.600
    • 1.20.10-gke.600
É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 solution Bare Metal ont été mises à jour avec du code pour corriger cette faille. Mettez à niveau vos clusters d'administrateur et vos clusters d'utilisateur vers l'une des versions suivantes :

  • 1.8.3
  • 1.7.4
Élevé

GCP-2021-017

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

GKE

Description Gravité
Mise à jour du 23/09/2021 :

Les conteneurs s'exécutant dans GKE Sandbox ne sont pas affectés par cette faille lorsque les attaques proviennent du conteneur.


Mise à jour du 15/09/2021 :

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. Elles peuvent provoquer un plantage du système d'exploitation ou une escalade vers la racine par un utilisateur non privilégié. 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 versions suivantes de GKE ont été mises à jour avec du code pour 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. Elles peuvent provoquer un plantage du système d'exploitation ou une escalade vers la racine par un utilisateur non privilégié. 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œud Linux pour les clusters Anthos on AWS ont été mises à jour avec du code pour 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é

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. Elles peuvent provoquer un plantage du système d'exploitation ou une escalade vers la racine par un utilisateur non privilégié. 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 et COS pour 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.9
  • 1.8.2
  • 1.7.3
  • 1.6.4 (Linux uniquement)

Consultez Historique des versions – Kubernetes et versions de noyau de nœud.

É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 : 19/10/2021
Référence : CVE-2021-30465

Mise à jour du 19/10/2021 : ajout de bulletins pour Anthos Clusters on VMware, Anthos Clusters on AWS et Anthos Clusters on Bare Metal.

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

Clusters Anthos sur

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 Anthos Clusters on VMware, é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. Il permet de corriger cette faille. Mettez à niveau Anthos Clusters on VMware vers l'une des versions suivantes :

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

Moyen

Clusters Anthos sur

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.

Étant donné qu'il s'agit d'une faille au niveau du système d'exploitation, les clusters Anthos sur AWS ne sont pas vulnérables.

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 ?

Assurez-vous que la version d'OS sur laquelle vous exécutez Anthos Clusters on AWS est mise à niveau vers la dernière version de l'OS avec un package runc mis à jour.

Aucun

Clusters Anthos sur

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.

Étant donné qu'il s'agit d'une faille au niveau du système d'exploitation, les clusters Anthos sur Bare Metal ne sont pas vulnérables.

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 ?

Assurez-vous que la version d'OS sur laquelle vous exécutez Anthos sur solution Bare Metal est mise à niveau vers la dernière version de l'OS avec un package runc mis à jour.

Aucun

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
Dernière mise à jour : 22/12/2021
Référence : CVE-2020-8554

Mise à jour du 22/12/2021 : utilise gcloud beta au lieu de la commande gcloud.

Mise à jour du 15/12/2021 : ajout d'un correctif pour GKE.

GKE

Description Gravité
Dernière mise à jour : 22/12/2021 : la commande GKE de la section suivante doit utiliser gcloud beta au lieu de la commande gcloud.

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

Dernière mise à jour : 15/12/2021 Pour GKE, l'atténuation suivante est désormais disponible :
  1. À partir de la version 1.21 de GKE, les services avec des adresses IP externes sont bloqués par un contrôleur d'admission DenyServiceExternalIPs activé par défaut pour les nouveaux clusters.
  2. Les clients qui passent à GKE version 1.21 peuvent bloquer des services avec des adresses IP externes à l'aide de la commande suivante :
    
    gcloud container clusters update –no-enable-service-externalips
    

Pour en savoir plus, consultez la page Renforcer la sécurité d'un cluster.


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é
Dernière mise à jour : 22/12/2021 : la commande GKE de la section suivante doit utiliser gcloud beta au lieu de la commande gcloud.

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

Dernière mise à jour : 15/12/2021 Pour GKE, l'atténuation suivante est désormais disponible :
  1. À partir de la version 1.21 de GKE, les services avec des adresses IP externes sont bloqués par un contrôleur d'admission DenyServiceExternalIPs activé par défaut pour les nouveaux clusters.
  2. Les clients qui passent à GKE version 1.21 peuvent bloquer des services avec des adresses IP externes à l'aide de la commande suivante :
    
    gcloud container clusters update –no-enable-service-externalips
    

Pour en savoir plus, consultez la page Renforcer la sécurité d'un cluster.


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é
Dernière mise à jour : 22/12/2021 : la commande GKE de la section suivante doit utiliser gcloud beta au lieu de la commande gcloud.

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

Dernière mise à jour : 15/12/2021 Pour GKE, l'atténuation suivante est désormais disponible :
  1. À partir de la version 1.21 de GKE, les services avec des adresses IP externes sont bloqués par un contrôleur d'admission DenyServiceExternalIPs activé par défaut pour les nouveaux clusters.
  2. Les clients qui passent à GKE version 1.21 peuvent bloquer des services avec des adresses IP externes à l'aide de la commande suivante :
    
    gcloud container clusters update –no-enable-service-externalips
    

Pour en savoir plus, consultez la page Renforcer la sécurité d'un cluster.


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é.