Boletines de seguridad

Todos los boletines de seguridad de los siguientes productos se describen en esta página:

  • Google Kubernetes Engine (GKE)
  • Clústeres de Anthos alojados en VMware (GKE On-Prem)
  • Clústeres de Anthos en AWS (GKE en AWS)
  • Clústeres de Anthos en equipos físicos

Las vulnerabilidades se suelen mantener en secreto y no se las puede divulgar hasta que las partes afectadas hayan tenido la oportunidad de tratar el tema. En estos casos, las notas de la versión de GKE tratan sobre “actualizaciones de seguridad” hasta que se apruebe la divulgación. En ese momento, las notas se actualizarán para reflejar la vulnerabilidad tratada en el parche.

Si deseas obtener más información sobre cómo Google administra las vulnerabilidades y parches de seguridad para GKE y Anthos, consulta Parches de seguridad.

Usa este feed XML para suscribirte a los boletines de seguridad de esta página. Suscribirse

GCP-2021-017

Fecha de publicación: 20/09/2021
Referencia: CVE-2021-33909
CVE-2021-33910

GKE

Descripción Gravedad

Se descubrieron dos vulnerabilidades de seguridad, CVE-2021-33909 y CVE-2021-33910, en el kernel de Linux que pueden provocar una falla del SO o una derivación a la raíz por parte de un usuario sin privilegios. Esta vulnerabilidad afecta a todos los sistemas operativos del nodo de GKE (COS y Ubuntu).

Detalles técnicos:

En CVE-2021-33909, la capa del sistema de archivos del kernel de Linux no restringe de forma correcta las asignaciones del búfer Seq, lo que genera un desbordamiento de números enteros, una escritura fuera de los límites y una elevación a raíz
Con CVE-2021-33910, systemd tiene una asignación de memoria con un valor de tamaño excesivo (que incluye strdupa y alloca para un ruta de acceso controlada por un atacante local) que provoca una falla del sistema operativo.

¿Qué debo hacer?

Las versiones de las imágenes de nodo de Linux para las siguientes versiones de GKE se actualizaron con un código a fin de corregir esta vulnerabilidad. Actualiza tus clústeres a una de las siguientes versiones:

  • 1.18.20-gke.901
  • 1.19.13-gke.1200
  • 1.20.9-gke.1000
  • 1.21.3-gke.901
Alto

Clústeres de Anthos alojados en

Descripción Gravedad

Se descubrieron dos vulnerabilidades de seguridad, CVE-2021-33909 y CVE-2021-33910, en el kernel de Linux que pueden provocar una falla del SO o una derivación a la raíz por parte de un usuario sin privilegios. Esta vulnerabilidad afecta a todos los sistemas operativos del nodo de GKE (COS y Ubuntu).

Detalles técnicos:

En CVE-2021-33909, la capa del sistema de archivos del kernel de Linux no restringe de forma correcta las asignaciones del búfer Seq, lo que genera un desbordamiento de números enteros, una escritura fuera de los límites y una elevación a raíz
Con CVE-2021-33910, systemd tiene una asignación de memoria con un valor de tamaño excesivo (que incluye strdupa y alloca para un ruta de acceso controlada por un atacante local) que provoca una falla del sistema operativo.

¿Qué debo hacer?

Las versiones de las imágenes de nodo de Linux para clústeres de Anthos en AWS se actualizaron con código a fin de solucionar esta vulnerabilidad. Actualiza tus clústeres a una de las siguientes versiones:

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

GCP-2021-015

Publicado: 2021-07-13
Actualizado: 2021-07-15
Referencia: CVE-2021-22555

GKE

Descripción Gravedad

Se descubrió una vulnerabilidad de seguridad nueva, CVE-2021-22555, en la que un actor malicioso con privilegios de CAP_NET_ADMIN puede causar una interrupción del contenedor en la raíz del host. Esta vulnerabilidad afecta a todos los clústeres de GKE y a los clústeres de Anthos alojados en VMware que ejecutan la versión 2.6.19 o una posterior de Linux.

Detalles técnicos

En este ataque, una escritura fuera de los límites en setsockopt en el subsistema netfilter de Linux puede permitir un daño en el montón (y, por lo tanto, la denegación del servicio) y la elevación de privilegios.

¿Qué debo hacer?

Las siguientes versiones de Linux en GKE se actualizaron con un código para corregir esta vulnerabilidad. Actualiza tus clústeres a una de las siguientes versiones:

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

¿Qué vulnerabilidad trata este parche?

CVE-2021-22555

Alto

Clústeres de Anthos alojados en

Descripción Gravedad

Se descubrió una vulnerabilidad de seguridad nueva, CVE-2021-22555, en la que un actor malicioso con privilegios de CAP_NET_ADMIN puede causar una interrupción del contenedor en la raíz del host. Esta vulnerabilidad afecta a todos los clústeres de GKE y a los clústeres de Anthos alojados en VMware que ejecutan la versión 2.6.19 o una posterior de Linux.

Detalles técnicos

En este ataque, una escritura fuera de los límites en setsockopt en el subsistema netfilter de Linux puede permitir un daño en el montón (y, por lo tanto, la denegación del servicio) y la elevación de privilegios.

¿Qué debo hacer?

Las siguientes versiones de los clústeres de Linux en Anthos en VMware se actualizaron con código para corregir esta vulnerabilidad. Actualiza tus clústeres a una de las siguientes versiones:

  • 1.8
  • 1.7.3
  • 1.6.4

¿Qué vulnerabilidad trata este parche?

CVE-2021-22555

Alto

GCP-2021-014

Publicado: 2021-07-05
Referencia: CVE-2021-34527

GKE

Descripción Gravedad

Microsoft publicó un boletín de seguridad sobre una vulnerabilidad de ejecución de código remoto (RCE), CVE-2021-34527, que afecta la cola de impresión en los servidores de Windows. El CERT Coordination Center (CERT/CC) publicó una nota de actualización sobre una vulnerabilidad relacionada, denominada "PrintNightmare", que también afecta las colas de impresión de Windows: PrintNightmare, Critical Windows Print Spooler Vulnerability.

¿Qué debo hacer?

No es necesario que realices ninguna acción. Los nodos de Windows para GKE no contienen el servicio de cola la impresión afectado como parte de la imagen base, por lo que las implementaciones de Windows para GKE no son vulnerables a este ataque.

¿Qué vulnerabilidades trata este boletín?

Alto

GCP-2021-012

Publicado: 2021-07-01
Actualizado: 2021-07-09
Referencia: CVE-2021-34824

GKE

Descripción Gravedad

¿Qué debo hacer?

Hace poco, el proyecto Istio divulgó una vulnerabilidad de seguridad nueva (CVE-2021-34824) que afecta a Istio. Istio contiene una vulnerabilidad que se puede explotar de forma remota, donde se puede acceder a las credenciales especificadas en el campo credentialName de Gateway y DestinationRule desde diferentes espacios de nombres.

Detalles técnicos:

La Gateway segura de Istio o las cargas de trabajo que usan DestinationRule pueden cargar claves privadas y certificados TLS desde los secretos de Kubernetes mediante la configuración de credentialName. En Istio 1.8 y versiones posteriores, los secretos se leen desde istiod y se transmiten a las puertas de enlace y las cargas de trabajo a través de XDS.

Por lo general, una implementación de carga de trabajo o puerta de enlace solo puede acceder a certificados y claves privadas TLS almacenados en el secreto de su espacio de nombres. Sin embargo, un error en istiod permite que un cliente con autorización para acceder a la API de Istio XDS recupere cualquier certificado y clave privada TLS almacenados en caché en istiod.

¿Qué debo hacer?

Los clústeres de GKE no ejecutan Istio de forma predeterminada y, cuando están habilitados, usan la versión 1.6 de Istio, que no es vulnerable a este ataque. Si instalaste o actualizaste Istio en el clúster a Istio 1.8 o una versión posterior, actualiza Istio a la versión compatible más reciente.

Alto

Clústeres de Anthos alojados en

Descripción Gravedad

¿Qué debo hacer?

Hace poco, el proyecto Istio divulgó una vulnerabilidad de seguridad nueva (CVE-2021-34824) que afecta a Istio. Istio contiene una vulnerabilidad que se puede explotar de forma remota, donde se puede acceder a las credenciales especificadas en el campo credentialName de Gateway y DestinationRule desde diferentes espacios de nombres.

Detalles técnicos:

La Gateway segura de Istio o las cargas de trabajo que usan DestinationRule pueden cargar claves privadas y certificados TLS desde los secretos de Kubernetes mediante la configuración de credentialName. En Istio 1.8 y versiones posteriores, los secretos se leen desde istiod y se transmiten a las puertas de enlace y las cargas de trabajo a través de XDS.

Por lo general, una implementación de carga de trabajo o puerta de enlace solo puede acceder a certificados y claves privadas TLS almacenados en el secreto de su espacio de nombres. Sin embargo, un error en istiod permite que un cliente con autorización para acceder a la API de Istio XDS recupere cualquier certificado y clave privada TLS almacenados en caché en istiod.

¿Qué debo hacer?

Los clústeres de Anthos alojados en VMware v1.6 y v1.7 no son vulnerables a este ataque. Los clústeres de Anthos alojados en VMware v1.8 son vulnerables.

Si usas los clústeres de Anthos alojados en VMware v1.8, actualiza a la siguiente versión con parche o posterior:

  • 1.8.0-gke.25
Alto

Clústeres de Anthos alojados en

Descripción Gravedad

¿Qué debo hacer?

Hace poco, el proyecto Istio divulgó una vulnerabilidad de seguridad nueva (CVE-2021-34824) que afecta a Istio. Istio contiene una vulnerabilidad que se puede explotar de forma remota, donde se puede acceder a las credenciales especificadas en el campo credentialName de Gateway y DestinationRule desde diferentes espacios de nombres.

Detalles técnicos:

La Gateway segura de Istio o las cargas de trabajo que usan DestinationRule pueden cargar claves privadas y certificados TLS desde los secretos de Kubernetes mediante la configuración de credentialName. En Istio 1.8 y versiones posteriores, los secretos se leen desde istiod y se transmiten a las puertas de enlace y las cargas de trabajo a través de XDS.

Por lo general, una implementación de carga de trabajo o puerta de enlace solo puede acceder a certificados y claves privadas TLS almacenados en el secreto de su espacio de nombres. Sin embargo, un error en istiod permite que un cliente con autorización para acceder a la API de Istio XDS recupere cualquier certificado y clave privada TLS almacenados en caché en istiod. Esta CVE afecta a los clústeres creados o actualizados con clústeres de Anthos en equipos físicos v1.8.0.

¿Qué debo hacer?

Anthos v1.6 y 1.7 no son vulnerables a este ataque. Si tienes clústeres v1.8.0, descarga y, luego, instala la versión 1.8.1 de bmctl y actualiza tus clústeres a la siguiente versión con parche:

  • 1.8.1
Alto

GCP-2021-011

Publicado: 2021-06-04
Actualizado: 2021-08-05
Referencia: CVE-2021-30465

GKE

Descripción Gravedad

Hace poco, la comunidad de seguridad divulgó una nueva vulnerabilidad de seguridad (CVE-2021-30465) que se encontró en runc y que tiene el potencial de permitir el acceso completo al sistema de archivos de un nodo.

En el caso de GKE, debido a que aprovechar esta vulnerabilidad requiere la capacidad de crear pods, calificamos la gravedad como MEDIA.

Detalles técnicos

El paquete runc es vulnerable a un ataque de intercambio de symlinks cuando se activa un volumen.

Para este ataque específico, un usuario puede aprovechar una condición de carrera iniciando múltiples pods en un solo nodo de manera simultánea, y todos comparten la misma activación de volumen con un symlink.

Si el ataque se realiza correctamente, uno de los pods activará el sistema de archivos del nodo con permisos de raíz.

¿Qué debo hacer?

Hay un parche nuevo para runc (1.0.0-rc95) que corrige esta vulnerabilidad.

Actualiza tu clúster de GKE a una de las siguientes versiones actualizadas:

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

Medio

GCP-2021-006

Publicado: 2021-05-11
Referencia: CVE-2021-31920

GKE

Descripción Gravedad

Hace poco, el proyecto Istio divulgó una vulnerabilidad de seguridad nueva (CVE-2021-31920) que afecta a Istio.

Istio contiene una vulnerabilidad que se puede exponer de forma remota, en la que una solicitud HTTP con varias barras o caracteres de barra de escape puede omitir la política de autorización de Istio cuando se usan reglas de autorización basadas en rutas.

¿Qué debo hacer?

Te recomendamos que actualices y vuelvas a configurar los clústeres de GKE. Ten en cuenta que es importante completar los dos pasos que se indican a continuación para resolver la vulnerabilidad de forma correcta:

  1. Actualiza tus clústeres: Completa las siguientes instrucciones para actualizar tus clústeres a las versiones de parche más recientes lo antes posible:
    • Si usas Istio on GKE 1.6, sigue estos pasos:

      La versión de parche más reciente es la 1.6.14-gke.3. Sigue las instrucciones de actualización para actualizar los clústeres a la versión más reciente.

    • Si usas Istio on GKE 1.4, sigue estos pasos:
    • Las versiones de Istio on GKE 1.4 ya no son compatibles con Istio y no agregamos correcciones de CVE para estas versiones. Sigue las instrucciones de actualización de Istio para actualizar los clústeres a la versión 1.6 y, luego, sigue las instrucciones anteriores a fin de obtener la versión más reciente de Istio en GKE 1.6.

  2. Configura Istio:

    Una vez que los clústeres tengan parches, debes volver a configurar Istio on GKE. Consulta la guía de prácticas recomendadas de seguridad para configurar tu sistema de forma correcta.

Alto

GCP-2021-004

Fecha de publicación: 2021-05-06
Referencia: CVE-2021-28683, CVE-2021-28682, CVE-2021-29258

GKE

Descripción Gravedad

Recientemente, los proyectos de Istio y Envoy anunciaron varias vulnerabilidades nuevas de seguridad (CVE-2021-28683, CVE-2021-28682 y CVE-2021-29258), que podrían permitir a un atacante bloquear Envoy.

Los clústeres de GKE no ejecutan Istio de forma predeterminada y no son vulnerables. Si Istio se instaló en un clúster y se configuró para exponer servicios a Internet, esos servicios pueden ser vulnerables a la denegación del servicio.

¿Qué debo hacer?

Para solucionar estas vulnerabilidades, actualiza tu plano de control de GKE a una de las siguientes versiones de parche:

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

Clústeres de Anthos alojados en

Descripción Gravedad

Recientemente, los proyectos de Istio y Envoy anunciaron varias vulnerabilidades nuevas de seguridad (CVE-2021-28683, CVE-2021-28682 y CVE-2021-29258), que podrían permitir a un atacante bloquear Envoy.

Los clústeres de Anthos alojados en VMware usan Envoy de forma predeterminada para el Ingress, por lo que los servicios de Ingress pueden ser vulnerables a la denegación del servicio.

¿Qué debo hacer?

Para corregir estas vulnerabilidades, actualiza tus clústeres de Anthos alojados en VMware a una de las siguientes versiones de parche cuando se lanzan:

  • 1.5.4
  • 1.6.3
  • 1.7.1
Medio

Clústeres de Anthos alojados en

Actualizado: 2021-05-06

Descripción Gravedad

Recientemente, los proyectos de Istio y Envoy anunciaron varias vulnerabilidades nuevas de seguridad (CVE-2021-28683, CVE-2021-28682 y CVE-2021-29258), que podrían permitir a un atacante bloquear Envoy.

Anthos en equipos físicos usa Envoy de forma predeterminada para Ingress, por lo que los servicios de Ingress pueden ser vulnerables a la denegación del servicio.

¿Qué debo hacer?

Para corregir estas vulnerabilidades, actualiza tu clúster de Anthos en equipos físicos a una de las siguientes versiones de parche cuando se lance:

  • 1.6.3
  • 1.7.1
Medio

GCP-2021-003

Publicado: 2021-04-19
Referencia: CVE-2021-25735

GKE

Descripción Gravedad

El proyecto de Kubernetes anunció recientemente una nueva vulnerabilidad de seguridad, CVE-2021-25735, que podría permitir que las actualizaciones del nodo omitan un webhook de admisión y validación.

En una situación en la que un atacante tiene privilegios suficientes y en la que se implementa un webhook de admisión y validación que usa propiedades del objeto Node antiguas (por ejemplo, campos en Node.NodeSpec), el atacante podría actualizar las propiedades de un nodo que podría provocar el compromiso del clúster. Ninguna de las políticas que aplican los controladores de admisión integrados de GKE y Kubernetes se ve afectada, pero recomendamos que los clientes verifiquen cualquier webhook de admisión adicional que hayan instalado.

¿Qué debo hacer?

Para solucionar esta vulnerabilidad, actualiza tu clúster de GKE a una de las siguientes versiones con parche:

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

Clústeres de Anthos alojados en

Descripción Gravedad

El proyecto de Kubernetes anunció recientemente una nueva vulnerabilidad de seguridad, CVE-2021-25735, que podría permitir que las actualizaciones del nodo omitan un webhook de admisión y validación.

En una situación en la que un atacante tiene privilegios suficientes y en la que se implementa un webhook de admisión y validación que usa propiedades del objeto Node antiguas (por ejemplo, campos en Node.NodeSpec), el atacante podría actualizar las propiedades de un nodo que podría provocar el compromiso del clúster. Ninguna de las políticas que aplican los controladores de admisión integrados de GKE y Kubernetes se ve afectada, pero recomendamos que los clientes verifiquen cualquier webhook de admisión adicional que hayan instalado.

¿Qué debo hacer?

En una versión de parche próxima, se incluirá una mitigación para esta vulnerabilidad.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

El proyecto de Kubernetes anunció recientemente una nueva vulnerabilidad de seguridad, CVE-2021-25735, que podría permitir que las actualizaciones del nodo omitan un webhook de admisión y validación.

En una situación en la que un atacante tiene privilegios suficientes y en la que se implementa un webhook de admisión y validación que usa propiedades del objeto Node antiguas (por ejemplo, campos en Node.NodeSpec), el atacante podría actualizar las propiedades de un nodo que podría provocar el compromiso del clúster. Ninguna de las políticas que aplican los controladores de admisión integrados de GKE y Kubernetes se ve afectada, pero recomendamos que los clientes verifiquen cualquier webhook de admisión adicional que hayan instalado.

¿Qué debo hacer?

En una versión de parche próxima, se incluirá una mitigación para esta vulnerabilidad.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

El proyecto de Kubernetes anunció recientemente una nueva vulnerabilidad de seguridad, CVE-2021-25735, que podría permitir que las actualizaciones del nodo omitan un webhook de admisión y validación.

En una situación en la que un atacante tiene privilegios suficientes y en la que se implementa un webhook de admisión y validación que usa propiedades del objeto Node antiguas (por ejemplo, campos en Node.NodeSpec), el atacante podría actualizar las propiedades de un nodo que podría provocar el compromiso del clúster. Ninguna de las políticas que aplican los controladores de admisión integrados de GKE y Kubernetes se ve afectada, pero recomendamos que los clientes verifiquen cualquier webhook de admisión adicional que hayan instalado.

¿Qué debo hacer?

En una versión de parche próxima, se incluirá una mitigación para esta vulnerabilidad.

Medio

GCP-2021-001

Publicado: 2021-01-28
Referencia: CVE-2021-3156

GKE

Descripción Gravedad

Recientemente, se descubrió una vulnerabilidad en la utilidad sudo de Linux, descrita en CVE-2021-3156, que puede permitir a un atacante con acceso de shell local sin privilegios en un sistema con sudo instalado escalar sus privilegios a la raíz del sistema.

Los clústeres de Google Kubernetes Engine (GKE) no se ven afectados por esta vulnerabilidad:

  • Los usuarios que están autorizados a establecer conexiones SSH a nodos de GKE ya se consideran muy privilegiados y pueden usar sudo para obtener privilegios raíz. La vulnerabilidad no produce rutas de elevación de privilegios adicionales en esta situación.
  • La mayoría de los contenedores del sistema de GKE se compilan a partir de imágenes base diferenciadas que no tienen una shell o un sudo instalados. Otras imágenes se compilan a partir de una imagen base de debian que no contiene sudo. Incluso si sudo estaba presente, el acceso a sudo dentro del contenedor no te otorga acceso al host debido al límite del contenedor.

¿Qué debo hacer?

Debido a que los clústeres de GKE no se ven afectados por esta vulnerabilidad, no es necesario que realices ninguna otra acción.

GKE aplicará el parche para esta vulnerabilidad en una versión próxima con cadencia regular.

Ninguna

Clústeres de Anthos alojados en

Descripción Gravedad

Recientemente, se descubrió una vulnerabilidad en la utilidad sudo de Linux, descrita en CVE-2021-3156, que puede permitir a un atacante con acceso de shell local sin privilegios en un sistema con sudo instalado escalar sus privilegios a la raíz del sistema.

Clústeres de Anthos alojados en VMware no se ve afectado por esta vulnerabilidad:

  • Los usuarios que están autorizados a usar nodos de clústeres de Anthos alojados en VMware ya se consideran que tienen privilegios elevados y pueden usar sudo para obtener privilegios raíz de diseño. La vulnerabilidad no produce rutas de elevación de privilegios adicionales en esta situación.
  • La mayoría de los contenedores del sistema de clústeres de Anthos alojados en VMware se compilan a partir de imágenes base diferenciadas que no tienen una shell o una sudo instalada. Otras imágenes se compilan a partir de una imagen base de debian que no contiene sudo. Incluso si sudo estaba presente, el acceso a sudo dentro del contenedor no te otorga acceso al host debido al límite del contenedor.

¿Qué debo hacer?

Debido a que clústeres de Anthos alojados en VMware no se ve afectado por esta vulnerabilidad, no es necesario que realices ninguna otra acción.

Clústeres de Anthos alojados en VMware tendrá el parche para esta vulnerabilidad que se aplicará en una versión futura con cadencia regular.

Ninguna

Clústeres de Anthos alojados en

Descripción Gravedad

Recientemente, se descubrió una vulnerabilidad en la utilidad sudo de Linux, descrita en CVE-2021-3156, que puede permitir a un atacante con acceso de shell local sin privilegios en un sistema con sudo instalado escalar sus privilegios a la raíz del sistema.

Clústeres de Anthos alojados en AWS no se ve afectado por esta vulnerabilidad:

  • Los usuarios que están autorizados a usar nodos de clústeres de Anthos alojados en AWS ya se consideran que tienen privilegios elevados y pueden usar sudo para obtener privilegios raíz de diseño. La vulnerabilidad no produce rutas de elevación de privilegios adicionales en esta situación.
  • La mayoría de los contenedores del sistema de clústeres de Anthos alojados en AWS se compilan a partir de imágenes base diferenciadas que no tienen una shell o una sudo instalada. Otras imágenes se compilan a partir de una imagen base de debian que no contiene sudo. Incluso si sudo estaba presente, el acceso a sudo dentro del contenedor no te otorga acceso al host debido al límite del contenedor.

¿Qué debo hacer?

Debido a que los clústeres de Anthos alojados en AWS no se ven afectados por esta vulnerabilidad, no es necesario que realices ninguna otra acción.

Los clústeres de Anthos alojados en AWS tendrán el parche para esta vulnerabilidad aplicado en una versión futura con cadencia regular.

Ninguna

Clústeres de Anthos alojados en

Descripción Gravedad

Recientemente, se descubrió una vulnerabilidad en la utilidad sudo de Linux, descrita en CVE-2021-3156, que puede permitir a un atacante con acceso de shell local sin privilegios en un sistema con sudo instalado escalar sus privilegios a la raíz del sistema.

La vulnerabilidad no afecta a los clústeres de Anthos en equipos físicos:

  • A los usuarios que están autorizados a usar SSH de Anthos en los nodos del equipo físico ya se consideran muy privilegiados y pueden usar sudo para obtener privilegios raíz de diseño. La vulnerabilidad no produce rutas de elevación de privilegios adicionales en esta situación.
  • La mayoría de los contenedores de Anthos en sistemas de equipos físicos se compilan a partir de imágenes base diferenciadas que no tienen una shell o una sudo instalada. Otras imágenes se compilan a partir de una imagen base de debian que no contiene sudo. Incluso si sudo estaba presente, el acceso a sudo dentro del contenedor no te otorga acceso al host debido al límite del contenedor.

¿Qué debo hacer?

Dado que esta vulnerabilidad no afecta a los clústeres de Anthos en equipos físicos, no es necesario que realices ninguna otra acción.

Anthos en equipos físicos aplicará el parche para esta vulnerabilidad en una versión próxima a cadencia normal.

Ninguna

GCP-2020-015

Publicado: 2020-12-07
Referencia: CVE-2020-8554

GKE

Descripción Gravedad

El proyecto de Kubernetes descubrió recientemente una nueva vulnerabilidad de seguridad, CVE-2020-8554, que puede permitir que un atacante que haya obtenido permisos cree un servicio de Kubernetes de tipo LoadBalancer o ClusterIP para interceptar el tráfico de red que se origina desde otros pods del clúster.

Esta vulnerabilidad por sí sola no otorga permisos a un atacante para crear un servicio de Kubernetes.

Todos los clústeres de Google Kubernetes Engine (GKE) se ven afectados por esta vulnerabilidad.

¿Qué debo hacer?

Es posible que Kubernetes deba realizar cambios de diseño incompatibles con versiones anteriores en una versión futura para solucionar la vulnerabilidad.

Si muchos usuarios comparten el acceso a tu clúster con permisos para crear servicios, como en un clúster multiusuario, considera aplicar una mitigación mientras tanto. Por ahora, el mejor enfoque para la mitigación es restringir el uso de IP externas en un clúster. ExternalIPs no es una función de uso general.

Restringe el uso de ExternalIPs en un clúster con uno de los siguientes métodos:

  1. Usa el controlador de políticas de Anthos o Gatekeeper con esta plantilla de restricciones y aplícala. Por ejemplo:
    
    # 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. O instala un controlador de admisión para evitar el uso de IP externas. El proyecto de Kubernetes proporcionó un controlador de admisión de muestra para esta tarea.

Como se mencionó en el anuncio de Kubernetes, no se proporciona ninguna mitigación para los servicios de tipo LoadBalancer, ya que, de forma predeterminada, solo se otorga a los usuarios y a los componentes del sistema con privilegios elevados el permiso container.services.updateStatus que se necesita para aprovechar esta vulnerabilidad.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

El proyecto de Kubernetes descubrió recientemente una nueva vulnerabilidad de seguridad, CVE-2020-8554, que puede permitir que un atacante que haya obtenido permisos cree un servicio de Kubernetes de tipo LoadBalancer o ClusterIP para interceptar el tráfico de red que se origina desde otros pods del clúster.

Esta vulnerabilidad por sí sola no otorga permisos a un atacante para crear un servicio de Kubernetes.

Todos los clústeres de Anthos alojados en VMware se ven afectados por esta vulnerabilidad.

¿Qué debo hacer?

Es posible que Kubernetes deba realizar cambios de diseño incompatibles con versiones anteriores en una versión futura para solucionar la vulnerabilidad.

Si muchos usuarios comparten el acceso a tu clúster con permisos para crear servicios, como en un clúster multiusuario, considera aplicar una mitigación mientras tanto. Por ahora, el mejor enfoque para la mitigación es restringir el uso de IP externas en un clúster. ExternalIPs no es una función de uso general.

Restringe el uso de ExternalIPs en un clúster con uno de los siguientes métodos:

  1. Usa el controlador de políticas de Anthos o Gatekeeper con esta plantilla de restricciones y aplícala. Por ejemplo:
    
    # 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. O instala un controlador de admisión para evitar el uso de IP externas. El proyecto de Kubernetes proporcionó un controlador de admisión de muestra para esta tarea.

Como se mencionó en el anuncio de Kubernetes, no se proporciona ninguna mitigación para los servicios de tipo LoadBalancer, ya que, de forma predeterminada, solo se otorga a los usuarios y a los componentes del sistema con privilegios elevados el permiso container.services.updateStatus que se necesita para aprovechar esta vulnerabilidad.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

El proyecto de Kubernetes descubrió recientemente una nueva vulnerabilidad de seguridad, CVE-2020-8554, que puede permitir que un atacante que haya obtenido permisos cree un servicio de Kubernetes de tipo LoadBalancer o ClusterIP para interceptar el tráfico de red que se origina desde otros pods del clúster.

Esta vulnerabilidad por sí sola no otorga permisos a un atacante para crear un servicio de Kubernetes.

Todos los clústeres de Anthos alojados en AWS se ven afectados por esta vulnerabilidad.

¿Qué debo hacer?

Es posible que Kubernetes deba realizar cambios de diseño incompatibles con versiones anteriores en una versión futura para solucionar la vulnerabilidad.

Si muchos usuarios comparten el acceso a tu clúster con permisos para crear servicios, como en un clúster multiusuario, considera aplicar una mitigación mientras tanto. Por ahora, el mejor enfoque para la mitigación es restringir el uso de IP externas en un clúster. ExternalIPs no es una función de uso general.

Restringe el uso de ExternalIPs en un clúster con uno de los siguientes métodos:

  1. Usa el controlador de políticas de Anthos o Gatekeeper con esta plantilla de restricciones y aplícala. Por ejemplo:
    
    # 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. O instala un controlador de admisión para evitar el uso de IP externas. El proyecto de Kubernetes proporcionó un controlador de admisión de muestra para esta tarea.

Como se mencionó en el anuncio de Kubernetes, no se proporciona ninguna mitigación para los servicios de tipo LoadBalancer, ya que, de forma predeterminada, solo se otorga a los usuarios y a los componentes del sistema con privilegios elevados el permiso container.services.updateStatus que se necesita para aprovechar esta vulnerabilidad.

Medio

GCP-2020-014

Publicado: 2020-10-20
Referencia: CVE-2020-8563, CVE-2020-8564, CVE-2020-8565, CVE-2020-8566

GKE

Actualizado: 2020-10-20

Descripción Gravedad

Hace poco, el proyecto de Kubernetes descubrió varios problemas que permiten la exposición de datos secretos cuando las opciones de registro detallado están habilitadas. Estos son los problemas:

  • CVE-2020-8563: Hay pérdidas de secretos en registros de kube-controller-manager del proveedor de vSphere.
  • CVE-2020-8564: Los secretos de archivos de configuración de Docker se filtran cuando el archivo es incorrecto y el nivel de registro >= 4.
  • CVE-2020-8565: Una corrección incompleta para CVE-2019-11250 en Kubernetes permite la pérdida de tokens en registros cuando logLevel >= 9. A este error lo encontró la seguridad de GKE.
  • CVE-2020-8566: Los adminSecrets de Ceph RBD se exponen en registros cuando loglevel >= 4.

GKE no se ve afectado.

¿Qué debo hacer?

No es necesario que realices ninguna otra acción debido a los niveles de registro detallado predeterminados de GKE.

Ninguna

Clústeres de Anthos alojados en

Actualizado: 2020-10-10

Descripción Gravedad

Hace poco, el proyecto de Kubernetes descubrió varios problemas que permiten la exposición de datos secretos cuando las opciones de registro detallado están habilitadas. Estos son los problemas:

  • CVE-2020-8563: Hay pérdidas de secretos en registros de kube-controller-manager del proveedor de vSphere.
  • CVE-2020-8564: Los secretos de archivos de configuración de Docker se filtran cuando el archivo es incorrecto y el nivel de registro >= 4.
  • CVE-2020-8565: Una corrección incompleta para CVE-2019-11250 en Kubernetes permite la pérdida de tokens en registros cuando logLevel >= 9. A este error lo encontró la seguridad de GKE.
  • CVE-2020-8566: Los adminSecrets de Ceph RBD se exponen en registros cuando loglevel >= 4.

Los clústeres de Anthos alojados en VMware no se ven afectados.

¿Qué debo hacer?

No es necesario que realices ninguna otra acción debido a los niveles de registro detallado predeterminados de GKE.

Ninguna

Clústeres de Anthos alojados en

Actualizado: 2020-10-20

Descripción Gravedad

Hace poco, el proyecto de Kubernetes descubrió varios problemas que permiten la exposición de datos secretos cuando las opciones de registro detallado están habilitadas. Estos son los problemas:

  • CVE-2020-8563: Hay pérdidas de secretos en registros de kube-controller-manager del proveedor de vSphere.
  • CVE-2020-8564: Los secretos de archivos de configuración de Docker se filtran cuando el archivo es incorrecto y el nivel de registro >= 4.
  • CVE-2020-8565: Una corrección incompleta para CVE-2019-11250 en Kubernetes permite la pérdida de tokens en registros cuando logLevel >= 9. A este error lo encontró la seguridad de GKE.
  • CVE-2020-8566: Los adminSecrets de Ceph RBD se exponen en registros cuando loglevel >= 4.

Los clústeres de Anthos alojados en AWS no se ven afectados.

¿Qué debo hacer?

No es necesario que realices ninguna otra acción debido a los niveles de registro detallado predeterminados de GKE.

Ninguna

GCP-2020-012

Publicado: 2020-09-14
Referencia: CVE-2020-14386

GKE

Descripción Gravedad

Hace poco, se descubrió una vulnerabilidad en el kernel de Linux, descrita en CVE-2020-14386, que puede permitir obtener privilegios raíz en el nodo host mediante el escape del contenedor.

Afecta a todos los nodos de GKE. Los Pods que se ejecutan en GKE Sandbox no pueden aprovechar esta vulnerabilidad.

¿Qué debo hacer?

Para mitigar esta vulnerabilidad, actualiza el plano de control y, luego, los nodos a una de las versiones con el parche que se mencionan a continuación:

  • 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

Para aprovechar esta vulnerabilidad, se requiere CAP_NET_RAW, pero muy pocos contenedores suelen requerir CAP_NET_RAW. Esta y otras capacidades potentes deben bloquearse de forma predeterminada a través de PodSecurityPolicy o del controlador de políticas:

Quita la capacidad CAP_NET_RAW de los contenedores con uno de los siguientes métodos:

  • Aplica el bloqueo de estas capacidades con PodSecurityPolicy, por ejemplo de la siguiente manera:
    
        # 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
  • También puedes usar el controlador de políticas o Gatekeeper con esta plantilla de restricción y aplicarla, por ejemplo de la siguiente manera:
    
        # 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"
  • O actualiza las especificaciones del 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

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2020-14386, que permite que los contenedores con CAP_NET_RAW escriban entre 1 y 10 bytes de memoria del kernel y posiblemente escapan el contenedor y obtienen privilegios de administrador en el nodo de host. Esta vulnerabilidad de seguridad tiene una calificación de gravedad alta.

Alto

Clústeres de Anthos alojados en

Actualizado: 2020-09-17

Descripción Gravedad

Hace poco, se descubrió una vulnerabilidad en el kernel de Linux, descrita en CVE-2020-14386, que puede permitir obtener privilegios raíz en el nodo host mediante el escape del contenedor.

Todos los nodos de clústeres de Anthos alojados en VMware se ven afectados.

¿Qué debo hacer?

Para corregir esta vulnerabilidad, actualiza el clúster a una versión de parche. Las siguientes versiones de {gke_on_prem_name}} contendrán la corrección para esta vulnerabilidad, y este boletín se actualizará cuando estén disponibles:

  • Clústeres de Anthos alojados en VMware 1.4.3, ya disponible
  • Clústeres de Anthos alojados en VMware 1.3.4 ya disponible.

Para aprovechar esta vulnerabilidad, se requiere CAP_NET_RAW, pero muy pocos contenedores suelen requerir CAP_NET_RAW. Esta y otras capacidades potentes deben bloquearse de forma predeterminada a través de PodSecurityPolicy o del controlador de políticas:

Quita la capacidad CAP_NET_RAW de los contenedores con uno de los siguientes métodos:

  • Aplica el bloqueo de estas capacidades con PodSecurityPolicy, por ejemplo de la siguiente manera:
    
        # 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
  • También puedes usar el controlador de políticas o Gatekeeper con esta plantilla de restricción y aplicarla, por ejemplo de la siguiente manera:
    
        # 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"
  • O actualiza las especificaciones del 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

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2020-14386, que permite que los contenedores con CAP_NET_RAW escriban entre 1 y 10 bytes de memoria del kernel y posiblemente escapan el contenedor y obtienen privilegios de administrador en el nodo de host. Esta vulnerabilidad de seguridad tiene una calificación de gravedad alta.

Alto

Clústeres de Anthos alojados en

Actualizado: 2020-10-13

Descripción Gravedad

Hace poco, se descubrió una vulnerabilidad en el kernel de Linux, descrita en CVE-2020-14386, que puede permitir obtener privilegios raíz en el nodo host mediante el escape del contenedor.

Todos los nodos de clústeres de Anthos alojados en AWS se ven afectados.

¿Qué debo hacer?

Para corregir esta vulnerabilidad, actualiza tu servicio de administración y tus clústeres de usuario a una versión con parche. Las próximas versiones de clústeres de Anthos alojados en AWS o versiones más recientes incluirán la corrección de esta vulnerabilidad, y este boletín se actualizará cuando estén disponibles:

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

Quita la capacidad CAP_NET_RAW de los contenedores con uno de los siguientes métodos:

  • Aplica el bloqueo de estas capacidades con PodSecurityPolicy, por ejemplo de la siguiente manera:
    
        # 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
  • También puedes usar el controlador de políticas o Gatekeeper con esta plantilla de restricción y aplicarla, por ejemplo de la siguiente manera:
    
        # 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"
  • O actualiza las especificaciones del 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

¿Qué vulnerabilidad trata este parche?

Este parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad CVE-2020-14386, que permite que los contenedores con CAP_NET_RAW escriban entre 1 y 10 bytes de memoria del kernel y posiblemente escapan el contenedor y obtienen privilegios de administrador en el nodo de host. Esta vulnerabilidad de seguridad tiene una calificación de gravedad alta.

Alto

GCP-2020-011

Publicado: 2020-07-24
Referencia: CVE-2020-8558

GKE

Descripción Gravedad

Se detectó hace poco una vulnerabilidad en las herramientas de redes, CVE-2020-8558, en Kubernetes. A veces, los servicios se comunican con otras aplicaciones que se ejecutan dentro del mismo Pod mediante la interfaz de bucle invertido local (127.0.0.1). Esta vulnerabilidad permite que un atacante con acceso a la red del clúster envíe tráfico a la interfaz de bucle invertido de Pods y nodos adyacentes. Podrían aprovecharse los servicios que dependen de que no se pueda acceder a la interfaz de bucle invertido fuera del Pod.

A fin de aprovechar esta vulnerabilidad en los clústeres de GKE, se requiere que un atacante tenga privilegios de administrador de red en el hosting de Google Cloud que aloja la VPC del clúster. Esta vulnerabilidad por sí sola no otorga privilegios de administrador de red a los atacantes. Por esta razón, a esta vulnerabilidad se le asignó una gravedad baja para GKE.

¿Qué debo hacer?

Para solucionar esta vulnerabilidad, actualiza los grupos de nodos del clúster a las siguientes versiones de GKE (y versiones posteriores):

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

¿Qué vulnerabilidad trata este parche?

Este parche corrige la siguiente vulnerabilidad: CVE-2020-8558.

Bajo

Clústeres de Anthos alojados en

Descripción Gravedad

Se detectó hace poco una vulnerabilidad en las herramientas de redes, CVE-2020-8558, en Kubernetes. A veces, los servicios se comunican con otras aplicaciones que se ejecutan dentro del mismo Pod mediante la interfaz de bucle invertido local (127.0.0.1). Esta vulnerabilidad permite que un atacante con acceso a la red del clúster envíe tráfico a la interfaz de bucle invertido de Pods y nodos adyacentes. Podrían aprovecharse los servicios que dependen de que no se pueda acceder a la interfaz de bucle invertido fuera del Pod.

¿Qué debo hacer?

Para corregir esta vulnerabilidad, actualiza el clúster a una versión de parche. Las siguientes versiones de clústeres de Anthos alojados en VMware o las versiones más recientes contienen la corrección para esta vulnerabilidad:

  • Clústeres de Anthos alojados en VMware 1.4.1

¿Qué vulnerabilidad trata este parche?

Este parche corrige la siguiente vulnerabilidad: CVE-2020-8558.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

Se detectó hace poco una vulnerabilidad en las herramientas de redes, CVE-2020-8558, en Kubernetes. A veces, los servicios se comunican con otras aplicaciones que se ejecutan dentro del mismo Pod mediante la interfaz de bucle invertido local (127.0.0.1). Esta vulnerabilidad permite que un atacante con acceso a la red del clúster envíe tráfico a la interfaz de bucle invertido de Pods y nodos adyacentes. Podrían aprovecharse los servicios que dependen de que no se pueda acceder a la interfaz de bucle invertido fuera del Pod.

A fin de aprovechar esta vulnerabilidad en los clústeres de usuario, se requiere que un atacante inhabilite las verificaciones de destino de origen en las instancias de EC2 en el clúster. El atacante debería tener permisos de IAM de AWS para ModifyInstanceAttribute o ModifyNetworkInterfaceAttribute en las instancias de EC2. Por esta razón, a esta vulnerabilidad se le asignó una gravedad baja para clústeres de Anthos alojados en AWS.

¿Qué debo hacer?

Para corregir esta vulnerabilidad, actualiza el clúster a una versión de parche. Se espera que las siguientes versiones de clústeres de Anthos alojados en AWS o versiones posteriores incluyan la corrección para esta vulnerabilidad:

  • Clústeres de Anthos alojados en AWS 1.4.1-gke.17

¿Qué vulnerabilidad trata este parche?

Este parche corrige la siguiente vulnerabilidad: CVE-2020-8558.

Bajo

GCP-2020-009

Publicado: 2020-07-15
Referencia: CVE-2020-8559

GKE

Descripción Gravedad

En la actualidad, se descubrió una vulnerabilidad de elevación de privilegios, CVE-2020-8559, en Kubernetes. Esta vulnerabilidad permite que un atacante que ya haya comprometido un nodo pueda ejecutar un comando en cualquier Pod del clúster. Por lo tanto, existe la posibilidad de que el atacante use el nodo ya comprometido para comprometer otros nodos y poder leer información o causar acciones destructivas.

Ten en cuenta que, para que un atacante pueda aprovechar esta vulnerabilidad, un nodo del clúster ya debe estar comprometido. Esta vulnerabilidad, por sí sola, no comprometerá ningún nodo del clúster.

¿Qué debo hacer?

Actualiza el clúster a una versión con parche. Los clústeres se actualizarán de forma automática durante las próximas semanas, y las versiones con parche estarán disponibles a partir del 19 de julio de 2020 para una programación de actualizaciones manuales acelerada. Las siguientes versiones del plano de control de GKE o versiones posteriores contienen la corrección para esta vulnerabilidad:

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

¿Qué vulnerabilidad trata este parche?

Estos parches mitigan la vulnerabilidad CVE-2020-8559. Esta se considera una vulnerabilidad de nivel medio para GKE, ya que requiere que el atacante tenga información de primera mano sobre el clúster, los nodos y las cargas de trabajo para aprovechar este ataque de manera efectiva, además de un nodo existente ya comprometido. Esta vulnerabilidad no le proporcionará un nodo comprometido a un atacante.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

En la actualidad, se descubrió una vulnerabilidad de elevación de privilegios, CVE-2020-8559, en Kubernetes. Esta vulnerabilidad permite que un atacante que ya haya comprometido un nodo pueda ejecutar un comando en cualquier Pod del clúster. Por lo tanto, existe la posibilidad de que el atacante use el nodo ya comprometido para comprometer otros nodos y poder leer información o causar acciones destructivas.

Ten en cuenta que, para que un atacante pueda aprovechar esta vulnerabilidad, un nodo del clúster ya debe estar comprometido. Esta vulnerabilidad, por sí sola, no comprometerá ningún nodo del clúster.

¿Qué debo hacer?

Actualiza tu clúster a una versión con parche. Las siguientes versiones de clústeres de Anthos alojados en VMware o las versiones más recientes contienen la corrección para esta vulnerabilidad:

  • Anthos 1.3.3
  • Anthos 1.4.1

¿Qué vulnerabilidad trata este parche?

Estos parches mitigan la vulnerabilidad CVE-2020-8559. Esta se considera una vulnerabilidad de nivel medio para GKE, ya que requiere que el atacante tenga información de primera mano sobre el clúster, los nodos y las cargas de trabajo para aprovechar este ataque de manera efectiva, además de un nodo existente ya comprometido. Esta vulnerabilidad no le proporcionará un nodo comprometido a un atacante.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

En la actualidad, se descubrió una vulnerabilidad de elevación de privilegios, CVE-2020-8559, en Kubernetes. Esta vulnerabilidad permite que un atacante que ya haya comprometido un nodo pueda ejecutar un comando en cualquier Pod del clúster. Por lo tanto, existe la posibilidad de que el atacante use el nodo ya comprometido para comprometer otros nodos y poder leer información o causar acciones destructivas.

Ten en cuenta que, para que un atacante pueda aprovechar esta vulnerabilidad, un nodo del clúster ya debe estar comprometido. Esta vulnerabilidad, por sí sola, no comprometerá ningún nodo del clúster.

¿Qué debo hacer?

La versión de clústeres de Anthos alojados en AWS (1.4.1, disponible a fines de julio de 2020), o versiones posteriores, incluye el parche para esta vulnerabilidad. Si usas una versión anterior, descarga una versión nueva de la herramienta de línea de comandos de anthos-gke y vuelve a crear los clústeres de administrador y de usuario.

¿Qué vulnerabilidad trata este parche?

Estos parches mitigan la vulnerabilidad CVE-2020-8559. Esta se considera una vulnerabilidad de nivel medio para GKE, ya que requiere que el atacante tenga información de primera mano sobre el clúster, los nodos y las cargas de trabajo para aprovechar este ataque de manera efectiva, además de un nodo existente ya comprometido. Esta vulnerabilidad no le proporcionará un nodo comprometido a un atacante.

Medio

GCP-2020-007

Publicado: 2020-06-01
Referencia: CVE-2020-8555

GKE

Descripción Gravedad

Recientemente, se descubrió la vulnerabilidad de falsificación de solicitudes del servidor (SSRF) CVE-2020-8555 en Kubernetes, que permitió a ciertos usuarios autorizados filtrar hasta 500 bytes de información sensible desde la red host del plano de control. En el plano de control de Google Kubernetes Engine (GKE), se usan controladores de Kubernetes a los que afecta esta vulnerabilidad. Te recomendamos actualizar el plano de control a la versión más reciente del parche, como se muestra a continuación. No requiere actualizar los nodos.

¿Qué debo hacer?

La mayoría de los clientes no debe realizar ninguna acción adicional. En la gran mayoría de los clústeres ya se está ejecutando la versión con el parche. Las siguientes versiones de GKE o las posteriores a ellas incluyen la corrección para esta vulnerabilidad:
  • 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

Los clústeres que usan canales de versiones ya están en las versiones del plano de control que tiene la mitigación.

¿Qué vulnerabilidad corrige este parche?

Estos parches mitigan la vulnerabilidad CVE-2020-8555. Esta tiene una calificación de vulnerabilidad media para GKE, ya que fue difícil aprovecharla debido a las medidas de endurecimiento del plano de control.

Un atacante con permisos para crear un Pod con ciertos tipos de volúmenes incluidos (GlusterFS, Quobyte, StorageFS, ScaleIO) o con permisos para crear un StorageClass puede hacer que kube-controller-manager cree solicitudes GET o POST sin un cuerpo de solicitud que controle el atacante desde la red de host de la instancia principal. En GKE rara vez se usan estos tipos de volúmenes, por lo que un uso nuevo de ellos puede ser un indicador de detección útil.

Combinados con un medio para que el atacante reciba los resultados filtrados del GET/POST (como los registros), puede provocar que se divulgue información sensible. Actualizamos los controladores de almacenamiento en cuestión para evitar la posibilidad de que ocurran tales fugas.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

Recientemente, se descubrió la vulnerabilidad de falsificación de solicitudes del servidor (SSRF) CVE-2020-8555 en Kubernetes, que permitió a ciertos usuarios autorizados filtrar hasta 500 bytes de información sensible desde la red host del plano de control. En el plano de control de Google Kubernetes Engine (GKE), se usan controladores de Kubernetes a los que afecta esta vulnerabilidad. Te recomendamos actualizar el plano de control a la versión más reciente del parche, como se detalla a continuación. No requiere actualizar los nodos.

¿Qué debo hacer?

Las siguientes versiones de clústeres de Anthos alojados en VMware (GKE On-Prem) o las versiones más recientes contienen la corrección para esta vulnerabilidad:

  • Anthos 1.3.0

Si usas una versión anterior, actualiza el clúster existente a una versión en la que se incluya la solución.

¿Qué vulnerabilidad trata este parche?

Estos parches mitigan la vulnerabilidad CVE-2020-8555. Esta tiene una calificación de vulnerabilidad media para GKE, ya que fue difícil aprovecharla debido a las medidas de endurecimiento del plano de control.

Un atacante con permisos para crear un Pod con ciertos tipos de volúmenes incluidos (GlusterFS, Quobyte, StorageFS, ScaleIO) o con permisos para crear un StorageClass puede hacer que kube-controller-manager cree solicitudes GET o POST sin un cuerpo de solicitud que controle el atacante desde la red de host de la instancia principal. En GKE rara vez se usan estos tipos de volúmenes, por lo que un uso nuevo de ellos puede ser un indicador de detección útil.

Combinados con un medio para que el atacante reciba los resultados filtrados del GET/POST (como los registros), puede provocar que se divulgue información sensible. Actualizamos los controladores de almacenamiento en cuestión para evitar la posibilidad de que ocurran tales fugas.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

Recientemente, se descubrió la vulnerabilidad de falsificación de solicitudes del servidor (SSRF) CVE-2020-8555 en Kubernetes, que permitió a ciertos usuarios autorizados filtrar hasta 500 bytes de información sensible desde la red host del plano de control. En el plano de control de Google Kubernetes Engine (GKE), se usan controladores de Kubernetes a los que afecta esta vulnerabilidad. Te recomendamos actualizar el plano de control a la versión más reciente del parche, como se detalla a continuación. No requiere actualizar los nodos.

¿Qué debo hacer?

clústeres de Anthos alojados en AWS (GKE en AWS) v0.2.0 o posterior ya incluye el parche para esta vulnerabilidad. Si usas una versión anterior, descarga una versión nueva de la herramienta de línea de comandos de anthos-gke y vuelve a crear los clústeres de administrador y de usuario.

¿Qué vulnerabilidad corrige este parche?

Estos parches mitigan la vulnerabilidad CVE-2020-8555. Esta tiene una calificación de vulnerabilidad media para GKE, ya que fue difícil aprovecharla debido a las medidas de endurecimiento del plano de control.

Un atacante con permisos para crear un Pod con ciertos tipos de volúmenes incluidos (GlusterFS, Quobyte, StorageFS, ScaleIO) o con permisos para crear un StorageClass puede hacer que kube-controller-manager cree solicitudes GET o POST sin un cuerpo de solicitud que controle el atacante desde la red de host de la instancia principal. En GKE rara vez se usan estos tipos de volúmenes, por lo que un uso nuevo de ellos puede ser un indicador de detección útil.

Combinados con un medio para que el atacante reciba los resultados filtrados del GET/POST (como los registros), puede provocar que se divulgue información sensible. Actualizamos los controladores de almacenamiento en cuestión para evitar la posibilidad de que ocurran tales fugas.

Medio

GCP-2020-006

Publicado: 2020-06-01
Referencia: Kubernetes issue 91507

GKE

Descripción Gravedad

Kubernetes divulgó una vulnerabilidad que permite que un contenedor con privilegios redireccione el tráfico de nodo a otro contenedor. El ataque no permite leer ni modificar el tráfico mutuo de TLS/SSH, como aquel entre el kubelet y el servidor de la API, o el tráfico desde aplicaciones mediante mTLS. Esta vulnerabilidad afecta a todos los nodos de Google Kubernetes Engine (GKE). Te recomendamos actualizar a la versión más reciente del parche, como se detalla a continuación.

¿Qué debo hacer?

Para mitigar esta vulnerabilidad, actualiza tu plano de control y, luego, tus nodos a una de las versiones con el parche que se mencionan a continuación. Los clústeres en los canales de versiones ya ejecutan una versión con el parche en el plano de control y los nodos:
  • 1.14.10-gke.36
  • 1.15.11-gke.15
  • 1.16.8-gke.15

Por lo general, muy pocos contenedores requieren CAP_NET_RAW. Esta y otras capacidades potentes se deben bloquear de forma predeterminada mediante PodSecurityPolicy o el controlador de políticas de Anthos:

Quita la capacidad CAP_NET_RAW de los contenedores con uno de los siguientes métodos:

  • Aplica el bloqueo de estas capacidades con PodSecurityPolicy, por ejemplo de la siguiente manera:
    
        # 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
  • También puedes usar el controlador de políticas o Gatekeeper con esta plantilla de restricción y aplicarla, por ejemplo de la siguiente manera:
    
        # 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"
  • O actualiza las especificaciones del 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

¿Qué vulnerabilidad corrige este parche?

El parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad descrita en el problema 91507 de Kubernetes: la capacidad CAP_NET_RAW (que se incluye en el conjunto de capacidades del contenedor predeterminado) por configurar de forma maliciosa la pila de IPv6 en el nodo y redireccionar el tráfico del nodo al contenedor que controla el atacante. Esto permitirá que el atacante intercepte o modifique el tráfico que se origina en el nodo o que se destina a este. El ataque no permite leer ni modificar el tráfico mutuo de TLS/SSH, como entre el kubelet y el servidor de la API, o el tráfico de aplicaciones con mTLS.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

Kubernetes divulgó una vulnerabilidad que permite que un contenedor con privilegios redireccione el tráfico de nodo a otro contenedor. El ataque no permite leer ni modificar el tráfico mutuo de TLS/SSH, como aquel entre el kubelet y el servidor de la API, o el tráfico desde aplicaciones mediante mTLS. Esta vulnerabilidad afecta a todos los nodos de Google Kubernetes Engine (GKE). Te recomendamos actualizar a la versión más reciente del parche, como se detalla a continuación.

¿Qué debo hacer?

A fin de mitigar esta vulnerabilidad para clústeres de Anthos alojados en VMware (GKE On-Prem), actualiza tus clústeres a la siguiente versión o una versión más reciente:
  • Anthos 1.3.2

Por lo general, muy pocos contenedores requieren CAP_NET_RAW. Esta y otras capacidades potentes se deben bloquear de forma predeterminada mediante el controlador de políticas de Anthos o la actualización de las especificaciones del pod:

Quita la capacidad CAP_NET_RAW de los contenedores con uno de los siguientes métodos:

  • Aplica el bloqueo de estas capacidades con PodSecurityPolicy, por ejemplo de la siguiente manera:
    
        # 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
  • También puedes usar el controlador de políticas o Gatekeeper con esta plantilla de restricción y aplicarla, por ejemplo de la siguiente manera:
    
        # 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"
  • O actualiza las especificaciones del 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

¿Qué vulnerabilidad corrige este parche?

El parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad descrita en el problema 91507 de Kubernetes: la capacidad CAP_NET_RAW (que se incluye en el conjunto de capacidades del contenedor predeterminado) por configurar de forma maliciosa la pila de IPv6 en el nodo y redireccionar el tráfico del nodo al contenedor que controla el atacante. Esto permitirá que el atacante intercepte o modifique el tráfico que se origina en el nodo o que se destina a este. El ataque no permite leer ni modificar el tráfico mutuo de TLS/SSH, como entre el kubelet y el servidor de la API, o el tráfico de aplicaciones con mTLS.

Medio

Clústeres de Anthos alojados en

Descripción Gravedad

Kubernetes divulgó una vulnerabilidad que permite que un contenedor con privilegios redireccione el tráfico de nodo a otro contenedor. El ataque no permite leer ni modificar el tráfico mutuo de TLS/SSH, como aquel entre el kubelet y el servidor de la API, o el tráfico desde aplicaciones mediante mTLS. Esta vulnerabilidad afecta a todos los nodos de Google Kubernetes Engine (GKE). Te recomendamos actualizar a la versión más reciente del parche, como se detalla a continuación.

¿Qué debo hacer?

Descarga la herramienta de línea de comandos de anthos-gke con la siguiente versión o una más reciente y vuelve a crear los clústeres de administrador y de usuario:

  • aws-0.2.1-gke.7

Por lo general, muy pocos contenedores requieren CAP_NET_RAW. Esta y otras capacidades potentes se deben bloquear de forma predeterminada mediante el controlador de políticas de Anthos o la actualización de las especificaciones del pod:

Quita la capacidad CAP_NET_RAW de los contenedores con uno de los siguientes métodos:

  • Aplica el bloqueo de estas capacidades con PodSecurityPolicy, por ejemplo de la siguiente manera:
    
        # 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
  • También puedes usar el controlador de políticas o Gatekeeper con esta plantilla de restricción y aplicarla, por ejemplo de la siguiente manera:
    
        # 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"
  • O actualiza las especificaciones del 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

¿Qué vulnerabilidad corrige este parche?

El parche mitiga la siguiente vulnerabilidad:

La vulnerabilidad descrita en el problema 91507 de Kubernetes: la capacidad CAP_NET_RAW (que se incluye en el conjunto de capacidades del contenedor predeterminado) por configurar de forma maliciosa la pila de IPv6 en el nodo y redireccionar el tráfico del nodo al contenedor que controla el atacante. Esto permitirá que el atacante intercepte o modifique el tráfico que se origina en el nodo o que se destina a este. El ataque no permite leer ni modificar el tráfico mutuo de TLS/SSH, como entre el kubelet y el servidor de la API, o el tráfico de aplicaciones con mTLS.

Medio

GCP‑2020‑005

Publicado: 2020-05-07
Actualizado: 2020-05-07
Referencia: CVE-2020-8835

GKE

Descripción Gravedad

Hace poco, se descubrió una vulnerabilidad en el kernel de Linux, descrita en CVE-2020-8835, que permite obtener privilegios de administrador en el nodo host mediante un escape de contenedor.

Esta vulnerabilidad afecta a los nodos de Google Kubernetes Engine (GKE) de Ubuntu que se ejecutan en GKE 1.16 o 1.17, por lo que te recomendamos actualizar a la versión de parche más reciente lo antes posible, como se muestra a continuación.

Los nodos que ejecutan Container-Optimized OS no se ven afectados. Los nodos que se ejecutan en clústeres de Anthos alojados en VMware no se ven afectados.

¿Qué debo hacer?

La mayoría de los clientes no debe realizar ninguna acción adicional. Solo se ven afectados los nodos que ejecutan Ubuntu en la versión 1.16 o 1.17 de GKE.

Para poder actualizar los nodos, primero debes actualizar la instancia principal a la versión más reciente. Este parche estará disponible en Kubernetes 1.16.8-gke.12, 1.17.4-gke.10 y en versiones más recientes. Haz un seguimiento de la disponibilidad de estos parches en las notas de la versión.

¿Qué vulnerabilidad corrige este parche?

Este parche mitiga la siguiente vulnerabilidad:

CVE-2020-8835 es una vulnerabilidad en la versión 5.5.0 y posteriores del kernel de Linux que permite que un contenedor malicioso (con una interacción mínima del usuario mediante un ejecutable) lea y escriba en la memoria del kernel para lograr la ejecución de código con permisos de administrador en el nodo host. Esta vulnerabilidad de seguridad tiene una calificación de gravedad alta.

Alto

GCP-2020-004

Publicado: 2020-05-07
Actualizado: 2020-05-07
Referencia: CVE-2019-11254

Clústeres de Anthos alojados en

Descripción Gravedad

Hace poco, se descubrió una vulnerabilidad en Kubernetes, descrita en CVE-2019-11254, que permite que cualquier usuario con autorización para realizar solicitudes POST ejecute un ataque de denegación del servicio de forma remota en un servidor de la API de Kubernetes. El Comité de seguridad de productos (PSC) de Kubernetes publicó información adicional sobre esta vulnerabilidad, que puedes encontrar aquí.

Puedes mitigar esta vulnerabilidad si limitas los clientes que tienen acceso a la red de los servidores de la API de Kubernetes.

¿Qué debo hacer?

Te recomendamos actualizar los clústeres a versiones del parche en las que se incluya la solución para esta vulnerabilidad en cuanto estén disponibles.

Estas son las versiones de parche que incluyen la corrección:

  • Anthos 1.3.0, que ejecuta la versión 1.15.7-gke.32 de Kubernetes

¿Qué vulnerabilidades trata este parche?

El parche corrige la siguiente vulnerabilidad de denegación del servicio (DoS):

CVE‑2019‑11254

Medio

GCP‑2020‑003

Publicado: 2020-03-31
Actualizado: 2020-03-31
Referencia: CVE-2019-11254

GKE

Descripción Gravedad

Hace poco, se descubrió una vulnerabilidad en Kubernetes, descrita en CVE-2019-11254, que permite que cualquier usuario con autorización para realizar solicitudes POST ejecute un ataque de denegación del servicio de forma remota en un servidor de la API de Kubernetes. El Comité de seguridad de productos (PSC) de Kubernetes publicó información adicional sobre esta vulnerabilidad, que puedes encontrar aquí.

Los clústeres de GKE que usan redes autorizadas para instancias principales y clústeres privados sin extremo público mitigan esta vulnerabilidad.

¿Qué debo hacer?

Te recomendamos que actualices el clúster a una versión de parche que incluya la corrección para esta vulnerabilidad.

Estas son las versiones de parche que incluyen la corrección:

  • 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

¿Qué vulnerabilidades corrige este parche?

El parche corrige la siguiente vulnerabilidad de denegación del servicio (DoS):

CVE‑2019‑11254

Medio

GCP‑2020‑002

Publicado: 2020-03-23
Actualizado: 2020-03-23
Referencia: CVE-2020-8551, CVE-2020-8552

GKE

Descripción Gravedad

Kubernetes divulgó dos vulnerabilidades de denegación del servicio: una que afecta al servidor de la API y otra que afecta a Kubelets. Para conocer más detalles, consulta los problemas de Kubernetes 8937789378.

¿Qué debo hacer?

Todos los usuarios de GKE están protegidos contra la vulnerabilidad CVE‑2020‑8551, excepto en los casos en que se permita que usuarios no confiables puedan enviar solicitudes en la red interna del clúster. El uso de redes autorizadas para instancias principales también brinda protección contra la vulnerabilidad CVE‑2020‑8552.

¿Cuándo se aplicarán parches para corregir estas vulnerabilidades?

Los parches para CVE‑2020‑8551 requieren actualizar los nodos. Estas son las versiones de parche que incluirán la mitigación:

  • 1.15.10‑gke.*
  • 1.16.7‑gke.*

Los parches para CVE‑2020‑8552 requieren actualizar las instancias principales. Estas son las versiones de parche que incluirán la mitigación:

  • 1.14.10‑gke.32
  • 1.15.10‑gke.*
  • 1.16.7‑gke.*
Medio

21 de enero de 2020

Publicado: 2020-01-21
Actualizado: 2020-01-24
Referencia: CVE-2019-11254

GKE

Descripción Gravedad

Actualización del 24/01/2020: El proceso para que las versiones con parche estén disponibles ya se está llevando a cabo y se completará el 25 de enero de 2020.


Microsoft divulgó una vulnerabilidad en la API de Windows Crypto y la validación de las firmas de curva elíptica. Si deseas obtener más información, puedes consultar el aviso de Microsoft al respecto.

¿Qué debo hacer?

La mayoría de los clientes no debe realizar ninguna acción adicional. Solo los nodos que se ejecutan en Windows Server se ven afectados.

Para mitigar la vulnerabilidad, los clientes que usan nodos en Windows Server deben actualizar los nodos y las cargas de trabajo en contenedores que se ejecutan en esos nodos a las versiones con parche.

Para actualizar los contenedores, sigue estos pasos:

Vuelve a compilar tus contenedores con las imágenes base de contenedor de Microsoft más actuales. Para ello, debes seleccionar una etiqueta servercore o nanoserver cuya última fecha de actualización sea el 14/01/2020 o posterior.

Actualización de nodos:

El proceso para que las versiones de parche estén disponibles ya se está llevando a cabo y se completará el 24 de enero de 2020.

Puedes esperar hasta esa fecha y actualizar el nodo a una versión de GKE con parche o puedes usar Windows Update en cualquier momento para implementar el último parche de Windows de forma manual.

Estas son las versiones con parche que contendrán la mitigación:

  • 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

¿Qué vulnerabilidades corrige este parche?

Este parche mitiga las siguientes vulnerabilidades:

CVE‑2020‑0601: Esta vulnerabilidad también se conoce como la Windows Crypto API Spoofing Vulnerability (Vulnerabilidad de falsificación de identidad de la API de Windows Crypto) y se puede usar para que los archivos ejecutables maliciosos parezcan confiables o a fin de permitir que el atacante realice ataques de intermediario y desencripte información confidencial sobre las conexiones TLS del software afectado.

Puntuación base de la NVD: 8.1 (alta)

Boletines de seguridad archivados

Para ver boletines de seguridad anteriores a 2020, consulta Archivo de boletines de seguridad.