Boletins de segurança

Todos os boletins de segurança dos seguintes produtos estão descritos nesta página:

  • Google Kubernetes Engine (GKE)
  • Clusters do Anthos no VMware (GKE On-Prem)
  • Clusters do Anthos no AWS (GKE na AWS)
  • Clusters do Anthos em bare metal

Geralmente, as vulnerabilidades são mantidas sob sigilo e não podem ser divulgadas até que as partes afetadas tenham a oportunidade de solucioná-las. Nesses casos, as notas de lançamento do produto mencionarão "atualizações de segurança" até que a divulgação seja liberada. No momento da liberação, as notas serão atualizadas para indicar a vulnerabilidade solucionada pelo patch.

Para mais informações sobre como o Google gerencia vulnerabilidades e patches de segurança para o GKE e o Anthos, consulte Patches de segurança.

Use este feed XML para se inscrever nos boletins de segurança desta página. Assinar

GCP-2021-018

Data de publicação: 15/09/2021
Referência: CVE-2021-25741

GKE;

Descrição Gravidade

Foi descoberto recentemente um problema de segurança no Kubernetes, CVE-2021-25741, em que um usuário pode criar um contêiner com montagens de volume de subcaminho para acessar arquivos e diretórios fora do volume, incluindo no sistema de arquivos do host.

Detalhes técnicos:

No problema CVE-2021-25741, o invasor pode criar um link simbólico de um emptyDir montado que redireciona para o sistema de arquivos raiz do nó ( / ). O kubelet seguirá o link simbólico e montará a raiz do host no contêiner.

O que fazer?

As versões a seguir do Google Kubernetes Engine foram atualizadas com código para corrigir essa vulnerabilidade. Faça upgrade dos clusters para uma das seguintes versões:

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

Clusters do Anthos no

Descrição Gravidade

Foi descoberto recentemente um problema de segurança no Kubernetes, CVE-2021-25741, em que um usuário pode criar um contêiner com montagens de volume de subcaminho para acessar arquivos e diretórios fora do volume, incluindo no sistema de arquivos do host.

Detalhes técnicos:

No problema CVE-2021-25741, o invasor pode criar um link simbólico de um emptyDir montado que redireciona para o sistema de arquivos raiz do nó ( / ). O kubelet seguirá o link simbólico e montará a raiz do host no contêiner.

O que fazer?

As seguintes versões dos clusters do Anthos na AWS foram atualizadas com código para corrigir essa vulnerabilidade. Faça upgrade dos clusters para uma das seguintes versões:

  • 1.8.2
Alta

GCP-2021-017

Publicado em: 01/09/2021
Atualizado em: 15/09/2020
Referência: CVE-2021-33909
CVE-2021-33910

GKE;

Descrição Gravidade

Atualizar:

As seguintes versões do GKE corrigem as vulnerabilidades:

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

Duas vulnerabilidades de segurança, CVE-2021-33909 e CVE-2021-33910, foram descobertas no kernel do Linux que podem levar a uma falha no SO ou um escalonamento para a raiz por um usuário sem privilégios. Essa vulnerabilidade afeta todos os sistemas operacionais dos nós do GKE (COS e Ubuntu).

Detalhes técnicos:

Na CVE-2021-33909 (em inglês), a camada do sistema de arquivos do kernel do Linux não restringe corretamente as alocações de buffer seq, levando a um estouro de números inteiros, uma gravação fora dos limites e escalonamento para raiz
Com a CVE-2021-33910, a systemd tem uma alocação de memória com um valor de tamanho excessivo (envolvendo strdupa e alloca para um pathname controlado por um invasor local que resulta em falha do sistema operacional.

O que fazer?

As versões de imagens de nó do Linux para as seguintes versões do GKE foram atualizadas com código para corrigir essa vulnerabilidade. Faça upgrade dos clusters para uma das seguintes versões:

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

Clusters do Anthos no

Descrição Gravidade

Duas vulnerabilidades de segurança, CVE-2021-33909 e CVE-2021-33910, foram descobertas no kernel do Linux que podem levar a uma falha no SO ou um escalonamento para a raiz por um usuário sem privilégios. Essa vulnerabilidade afeta todos os sistemas operacionais dos nós do GKE (COS e Ubuntu).

Detalhes técnicos:

Na CVE-2021-33909 (em inglês), a camada do sistema de arquivos do kernel do Linux não restringe corretamente as alocações de buffer seq, levando a um estouro de números inteiros, uma gravação fora dos limites e escalonamento para raiz
Com a CVE-2021-33910, a systemd tem uma alocação de memória com um valor de tamanho excessivo (envolvendo strdupa e alloca para um pathname controlado por um invasor local que resulta em falha do sistema operacional.

O que fazer?

As versões das imagens de nó do Linux para clusters do Anthos na AWS foram atualizadas com código para corrigir essa vulnerabilidade. Faça upgrade dos clusters para uma das seguintes versões:

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

GCP-2021-015

Publicado em: 13/07/2021
Atualizado em: 15/07/2021
Referência: CVE-2021-22555

GKE

Descrição Gravidade

Foi descoberta uma nova vulnerabilidade de segurança, a CVE-2021-22555 (em inglês), em que um ator mal-intencionado com privilégios CAP_NET_ADMIN pode causar uma falha de root no contêiner. Essa vulnerabilidade afeta todos os clusters do GKE e clusters do Anthos no VMware que executam o Linux versão 2.6.19 ou posterior.

Detalhes técnicos

Nesse ataque, uma gravação fora dos limites em setsockopt no subsistema netfilter no Linux pode permitir uma corrupção de heap (e, portanto, negação de serviço) e o escalonamento de privilégios.

O que fazer?

As seguintes versões do Linux no GKE foram atualizadas com código para corrigir essa vulnerabilidade. Faça upgrade dos clusters para uma das seguintes versões:

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

Qual vulnerabilidade é corrigida por esse patch?

CVE-2021-22555

Alto

Clusters do Anthos no

Descrição Gravidade

Foi descoberta uma nova vulnerabilidade de segurança, a CVE-2021-22555 (em inglês), em que um ator mal-intencionado com privilégios CAP_NET_ADMIN pode causar uma falha de root no contêiner. Essa vulnerabilidade afeta todos os clusters do GKE e clusters do Anthos no VMware que executam o Linux versão 2.6.19 ou posterior.

Detalhes técnicos

Nesse ataque, uma gravação fora dos limites em setsockopt no subsistema netfilter no Linux pode permitir uma corrupção de heap (e, portanto, negação de serviço) e o escalonamento de privilégios.

O que fazer?

As seguintes versões do Linux nos clusters do Anthos no VMware foram atualizadas com código para corrigir essa vulnerabilidade. Faça upgrade dos clusters para uma das seguintes versões:

  • 1.8
  • 1.7.3
  • 1.6.4

Qual vulnerabilidade é corrigida por esse patch?

CVE-2021-22555

Alto

GCP-2021-014

Data de publicação: 05/07/2021
Referência: CVE-2021-34527

GKE

Descrição Gravidade

A Microsoft publicou um boletim de segurança sobre uma vulnerabilidade de execução remota de código (RCE, na sigla em inglês), CVE-2021-34527, que afeta o spooler de impressão nos servidores do Windows. O CERT Coordination Center (CERT/CC) publicou uma nota de atualização sobre uma vulnerabilidade relacionada, chamada de "Printnightmare", que também afeta os spoolers de impressão do Windows. Vulnerabilidade do Spooler de impressão crítica do Windows

O que fazer?

Nenhuma ação é necessária. Os nós do GKE no Windows não contêm o serviço Spooler afetado como parte da imagem base. Por isso, as implantações do GKE no Windows não estão vulneráveis a esse ataque.

Quais vulnerabilidades são corrigidas por esse boletim?

Alto

GCP-2021-012

Publicado em: 01/07/2021
Atualizado em: 09/07/2021
Referência: CVE-2021-34824

GKE

Descrição Gravidade

O que fazer?

Recentemente, o projeto Istio divulgou uma nova vulnerabilidade de segurança (CVE-2021-34824) que afeta o Istio. O Istio tem uma vulnerabilidade que pode ser explorada remotamente, em que é possível acessar as credenciais especificadas nos campos "gateway" e "DestinationRule "credentialName" de diferentes namespaces.

Detalhes técnicos:

O gateway seguro do Istio ou as cargas de trabalho que usam a DestinationRule podem carregar chaves privadas e certificados TLS com base em secrets do Kubernetes pela configuração credentialName. A partir do Istio 1.8, os secrets são lidos no istiod e transmitidos para gateways e cargas de trabalho pelo XDS.

Normalmente, uma implantação de gateway ou carga de trabalho só consegue acessar certificados TLS e chaves privadas armazenadas no secret dentro do namespace. No entanto, um bug no istiod permite que um cliente autorizado acesse a API Istio XDS e recupere qualquer certificado TLS e chaves privadas armazenadas em cache em istiod.

O que fazer?

Por padrão, os clusters do GKE não executam o Istio e, quando ativados, usam a versão 1.6 do Istio, que não é vulnerável a esse ataque. Se você instalou ou fez upgrade do Istio no cluster para o Istio 1.8 ou posterior, faça upgrade do Istio para a versão compatível mais recente.

Alto

Clusters do Anthos no

Descrição Gravidade

O que fazer?

Recentemente, o projeto Istio divulgou uma nova vulnerabilidade de segurança (CVE-2021-34824) que afeta o Istio. O Istio tem uma vulnerabilidade que pode ser explorada remotamente, em que é possível acessar as credenciais especificadas nos campos "gateway" e "DestinationRule "credentialName" de diferentes namespaces.

Detalhes técnicos:

O gateway seguro do Istio ou as cargas de trabalho que usam a DestinationRule podem carregar chaves privadas e certificados TLS com base em secrets do Kubernetes pela configuração credentialName. A partir do Istio 1.8, os secrets são lidos no istiod e transmitidos para gateways e cargas de trabalho pelo XDS.

Normalmente, uma implantação de gateway ou carga de trabalho só consegue acessar certificados TLS e chaves privadas armazenadas no secret dentro do namespace. No entanto, um bug no istiod permite que um cliente autorizado acesse a API Istio XDS e recupere qualquer certificado TLS e chaves privadas armazenadas em cache em istiod.

O que fazer?

Os clusters do Anthos no VMware v1.6 e v1.7 não são vulneráveis a esse ataque. Os clusters do Anthos no VMware v1.8 são vulneráveis.

Se você estiver usando clusters do Anthos no VMware v1.8, faça upgrade para a seguinte versão com patch ou posterior:

  • 1.8.0-gke.25
Alto

Clusters do Anthos no

Descrição Gravidade

O que fazer?

Recentemente, o projeto Istio divulgou uma nova vulnerabilidade de segurança (CVE-2021-34824) que afeta o Istio. O Istio tem uma vulnerabilidade que pode ser explorada remotamente, em que é possível acessar as credenciais especificadas nos campos "gateway" e "DestinationRule "credentialName" de diferentes namespaces.

Detalhes técnicos:

O gateway seguro do Istio ou as cargas de trabalho que usam a DestinationRule podem carregar chaves privadas e certificados TLS com base em secrets do Kubernetes pela configuração credentialName. A partir do Istio 1.8, os secrets são lidos no istiod e transmitidos para gateways e cargas de trabalho pelo XDS.

Normalmente, uma implantação de gateway ou carga de trabalho só consegue acessar certificados TLS e chaves privadas armazenadas no secret dentro do namespace. No entanto, um bug no istiod permite que um cliente autorizado acesse a API Istio XDS e recupere qualquer certificado TLS e chaves privadas armazenadas em cache em istiod. Os clusters criados ou atualizados com clusters do Anthos no bare metal v1.8.0 são afetados por essa CVE.

O que fazer?

O Anthos v1.6 e 1.7 não são vulneráveis a esse ataque. Se você tiver clusters v1.8.0, faça o download e instale a versão 1.8.1 do bmctl e faça upgrade dos clusters para a seguinte versão com patch:

  • 1.8.1
Alto

GCP-2021-011

Publicado em: 04/06/2021
Atualizado em: 05/08/2021
Referência: CVE-2021-30465

GKE;

Descrição Gravidade

A comunidade de segurança divulgou recentemente uma nova vulnerabilidade de segurança, a CVE-2021-30465, encontrada no runc e que tem o potencial de permitir acesso total a um sistema de arquivos de nós.

Para o GKE, como a exploração dessa vulnerabilidade requer a capacidade de criar pods, classificamos a gravidade dessa vulnerabilidade como "MÉDIA".

Detalhes técnicos

O pacote runc é vulnerável a um ataque de troca de link simbólico ao montar um volume.

Para esse ataque específico, um usuário pode explorar uma disputa ao iniciar vários pods em um único nó simultaneamente, todos com a mesma quantidade de volume com um link simbólico.

Se o ataque for bem-sucedido, um dos pods ativará o sistema de arquivos do nó com permissões raiz.

O que fazer?

Há um patch recém-lançado para runc (1.0.0-rc95) que corrige essa vulnerabilidade.

Faça upgrade do cluster do GKE para uma das versões atualizadas a seguir:

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

Médio

GCP-2021-006

Data de publicação: 11/05/2021
Referência: CVE-2021-31920

GKE

Descrição Gravidade

Recentemente, o projeto Istio divulgou uma nova vulnerabilidade de segurança (CVE-2021-31920) que afeta o Istio.

O Istio tem uma vulnerabilidade que pode ser explorada remotamente, em que uma solicitação HTTP com várias barras ou caracteres de barra de escape pode ignorar a política de autorização do Istio quando regras de autorização com base em caminho forem usadas.

O que fazer?

É altamente recomendável atualizar e reconfigurar os clusters do GKE. É importante concluir as duas etapas abaixo para resolver a vulnerabilidade:

  1. Atualize os clusters: preencha as instruções a seguir para fazer o upgrade dos clusters para as versões de patch mais recentes assim que possível:
    • Se você estiver usando o Istio no GKE 1.6:

      A versão de lançamento mais recente do patch é 1.6.14-gke.3. Siga as instruções de upgrade para fazer upgrade dos clusters para a versão mais recente.

    • Se você estiver usando o Istio no GKE 1.4:
    • As versões do Istio no GKE 1.4 não são mais compatíveis com o Istio, e não oferecemos suporte a correções de CVE para essas versões. Siga as instruções de upgrade do Istio (em inglês) para fazer upgrade dos clusters para 1.6. Depois, siga as instruções acima para conseguir a versão mais recente do Istio no GKE 1.6.

  2. Configure o Istio:

    Depois que os clusters forem corrigidos, você precisará reconfigurar o Istio no GKE. Consulte o guia de práticas recomendadas de segurança para configurar corretamente o sistema.

Alto

GCP-2021-004

Data de publicação: 06/05 2021
Referência: CVE-2021-28683, CVE-2021-28682, CVE-2021-29258

GKE

Descrição Gravidade

Os projetos do Envoy e do Istio recentemente anunciaram várias novas vulnerabilidades de segurança (CVE-2021-28683, CVE-2021-28682). e CVE-2021-29258, que permitem que um invasor cause uma falha no Envoy.

Os clusters do GKE não executam o Istio por padrão e não são vulneráveis. Se o Istio tiver sido instalado em um cluster e configurado para expor serviços à Internet, esses serviços poderão ficar vulneráveis a ataques de negação de serviço.

O que fazer?

Para corrigir essas vulnerabilidades, faça upgrade do seu plano de controle do GKE para uma das seguintes versões com patch:

  • 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
Média

Clusters do Anthos no

Descrição Gravidade

Os projetos do Envoy e do Istio recentemente anunciaram várias novas vulnerabilidades de segurança (CVE-2021-28683, CVE-2021-28682). e CVE-2021-29258, que permitem que um invasor cause uma falha no Envoy.

Os clusters do Anthos no VMware usam o Envoy por padrão para o Ingress. Portanto, os serviços do Ingress podem estar vulneráveis à negação de serviço.

O que fazer?

Para corrigir essas vulnerabilidades, faça upgrade dos clusters do Anthos no VMware para uma das seguintes versões com patch quando elas forem lançadas:

  • 1.5.4
  • 1.6.3
  • 1.7.1
Média

Clusters do Anthos no

Atualizado em: 06/05/2021

Descrição Gravidade

Os projetos do Envoy e do Istio recentemente anunciaram várias novas vulnerabilidades de segurança (CVE-2021-28683, CVE-2021-28682). e CVE-2021-29258, que permitem que um invasor cause uma falha no Envoy.

O Anthos em bare metal usa o Envoy por padrão para o Ingress. Portanto, os serviços Ingress podem ser vulneráveis à negação de serviço.

O que fazer?

Para corrigir essas vulnerabilidades, faça upgrade do cluster do Anthos no bare metal para uma das seguintes versões com patch quando elas forem lançadas:

  • 1.6.3
  • 1.7.1
Média

GCP-2021-003

Data de publicação: 19/04/2021
Referência: CVE-2021-25735

GKE

Descrição Gravidade

O projeto do Kubernetes anunciou recentemente uma nova vulnerabilidade de segurança, CVE-2021-25735, que permite que as atualizações de nó ignorem uma validação do webhook de admissão.

Em um cenário em que um invasor tem privilégios suficientes e em que uma validação do webhook de admissão foi implementada que usa propriedades de objetos Node antigas (por exemplo, campos em Node.NodeSpec), o invasor pode atualizar propriedades de um nó que podem levar a um comprometimento do cluster. Nenhuma das políticas aplicadas pelos controladores de admissão integrados do GKE e do Kubernetes é afetada. No entanto, recomendamos que os clientes verifiquem os webhooks de admissão adicionais instalados.

O que fazer?

Para corrigir essa vulnerabilidade, faça o upgrade do cluster do GKE para uma das seguintes versões com patch:

  • 1.18.17-gke.900
  • 1.19.9-gke.900
  • 1.20.5-gke.900
Média

Clusters do Anthos no

Descrição Gravidade

O projeto do Kubernetes anunciou recentemente uma nova vulnerabilidade de segurança, CVE-2021-25735, que permite que as atualizações de nó ignorem uma validação do webhook de admissão.

Em um cenário em que um invasor tem privilégios suficientes e em que uma validação do webhook de admissão foi implementada que usa propriedades de objetos Node antigas (por exemplo, campos em Node.NodeSpec), o invasor pode atualizar propriedades de um nó que podem levar a um comprometimento do cluster. Nenhuma das políticas aplicadas pelos controladores de admissão integrados do GKE e do Kubernetes é afetada. No entanto, recomendamos que os clientes verifiquem os webhooks de admissão adicionais instalados.

O que fazer?

Uma versão de patch futura incluirá uma mitigação dessa vulnerabilidade.

Média

Clusters do Anthos no

Descrição Gravidade

O projeto do Kubernetes anunciou recentemente uma nova vulnerabilidade de segurança, CVE-2021-25735, que permite que as atualizações de nó ignorem uma validação do webhook de admissão.

Em um cenário em que um invasor tem privilégios suficientes e em que uma validação do webhook de admissão foi implementada que usa propriedades de objetos Node antigas (por exemplo, campos em Node.NodeSpec), o invasor pode atualizar propriedades de um nó que podem levar a um comprometimento do cluster. Nenhuma das políticas aplicadas pelos controladores de admissão integrados do GKE e do Kubernetes é afetada. No entanto, recomendamos que os clientes verifiquem os webhooks de admissão adicionais instalados.

O que fazer?

Uma versão de patch futura incluirá uma mitigação dessa vulnerabilidade.

Média

Clusters do Anthos no

Descrição Gravidade

O projeto do Kubernetes anunciou recentemente uma nova vulnerabilidade de segurança, CVE-2021-25735, que permite que as atualizações de nó ignorem uma validação do webhook de admissão.

Em um cenário em que um invasor tem privilégios suficientes e em que uma validação do webhook de admissão foi implementada que usa propriedades de objetos Node antigas (por exemplo, campos em Node.NodeSpec), o invasor pode atualizar propriedades de um nó que podem levar a um comprometimento do cluster. Nenhuma das políticas aplicadas pelos controladores de admissão integrados do GKE e do Kubernetes é afetada. No entanto, recomendamos que os clientes verifiquem os webhooks de admissão adicionais instalados.

O que fazer?

Uma versão de patch futura incluirá uma mitigação dessa vulnerabilidade.

Média

GCP-2021-001

Data de publicação: 28/01/2021
Referência: CVE-2021-3156

GKE

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no utilitário sudo do Linux, descrito em CVE-2021-3156, que pode permitir que um invasor com acesso shell local não privilegiado em um sistema com o sudo instalado encaminhe seus privilégios à raiz do sistema.

Os clusters do Google Kubernetes Engine (GKE) não são afetados por esta vulnerabilidade:

  • Os usuários autorizados a nós SSH para GKE já são considerados altamente privilegiados e podem usar sudo para conseguir privilégios raiz desde a criação. A vulnerabilidade não produz mais caminhos de escalonamento de privilégios nesse cenário.
  • A maioria dos contêineres do sistema do GKE é criada com base em imagens de base distroless, que não têm um shell ou sudo instalados. Outras imagens são criadas de uma imagem base do Debian que não contém sudo. Mesmo que sudo esteja presente, o acesso a sudo no contêiner não dá acesso ao host devido ao limite do contêiner.

O que fazer?

Como os clusters do GKE não são afetados por essa vulnerabilidade, nenhuma outra ação é necessária.

O GKE terá o patch dessa vulnerabilidade aplicado em uma próxima versão na cadência regular.

Nenhum

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no utilitário sudo do Linux, descrito em CVE-2021-3156, que pode permitir que um invasor com acesso shell local não privilegiado em um sistema com o sudo instalado encaminhe seus privilégios à raiz do sistema.

Os clusters do Anthos no VMware não são afetados por essa vulnerabilidade:

  • Os usuários autorizados a SSH para nós dos clusters do Anthos no VMware já são considerados altamente privilegiados e podem usar sudo para conseguir privilégios raiz desde a criação. A vulnerabilidade não produz mais caminhos de escalonamento de privilégios nesse cenário.
  • A maioria dos contêineres do sistema dos clusters do Anthos no VMware são criadas com base em imagens de base distroless, que não têm um shell ou sudo instalados. Outras imagens são criadas de uma imagem base do Debian que não contém sudo. Mesmo que sudo esteja presente, o acesso a sudo no contêiner não concede acesso ao host devido ao limite do contêiner.

O que fazer?

Como os clusters do Anthos nos clusters do VMware não são afetados por essa vulnerabilidade, nenhuma outra ação é necessária.

Os clusters do Anthos no VMware terão o patch para essa vulnerabilidade aplicado em uma próxima versão na cadência normal.

Nenhum

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no utilitário sudo do Linux, descrito em CVE-2021-3156, que pode permitir que um invasor com acesso shell local não privilegiado em um sistema com o sudo instalado encaminhe seus privilégios à raiz do sistema.

Os clusters do Anthos na AWS não são afetados por essa vulnerabilidade:

  • Os usuários autorizados a SSH para clusters do Anthos em nós da AWS já são considerados altamente privilegiados e podem usar sudo para ter privilégios raiz desde a criação. A vulnerabilidade não produz mais caminhos de escalonamento de privilégios nesse cenário.
  • A maioria dos contêineres do sistema dos clusters do Anthos no VMware são criadas com base em imagens de base distroless, que não têm um shell ou sudo instalados. Outras imagens são criadas de uma imagem base do Debian que não contém sudo. Mesmo que sudo esteja presente, o acesso a sudo no contêiner não concede acesso ao host devido ao limite do contêiner.

O que fazer?

Como os clusters do Anthos em clusters da AWS não são afetados por essa vulnerabilidade, nenhuma outra ação é necessária.

Os clusters do Anthos na AWS terão o patch dessa vulnerabilidade aplicado em uma próxima versão na cadência regular.

Nenhum

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no utilitário sudo do Linux, descrito em CVE-2021-3156, que pode permitir que um invasor com acesso shell local não privilegiado em um sistema com o sudo instalado encaminhe seus privilégios à raiz do sistema.

Os clusters do Anthos em Bare Metal não são afetados por essa vulnerabilidade:

  • Os usuários autorizados a SSH para nós do Anthos em Bare Metal já são considerados altamente privilegiados e podem usar sudo para ter privilégios de raiz desde a criação. A vulnerabilidade não produz mais caminhos de escalonamento de privilégios nesse cenário.
  • A maioria dos contêineres de sistema do Anthos em Bare Metal são criados a partir de imagens base distroless que não têm um shell ou sudo instalados. Outras imagens são criadas de uma imagem base do Debian que não contém sudo. Mesmo que sudo esteja presente, o acesso a sudo no contêiner não concede acesso ao host devido ao limite do contêiner.

O que fazer?

Como os clusters do Anthos em Bare Metal não são afetados por essa vulnerabilidade, nenhuma outra ação é necessária.

O Anthos em Bare Metal terá o patch para essa vulnerabilidade aplicado em uma próxima versão na cadência normal.

Nenhum

GCP-2020-015

Data de publicação: 07/12/2020
Referência: CVE-2020-8554

GKE

Descrição Gravidade

O projeto Kubernetes descobriu recentemente uma nova vulnerabilidade de segurança, CVE-2020-8554, que permite que um invasor que conseguiu permissões para criar um serviço do Kubernetes do tipo LoadBalancer ou ClusterIP intercepte o tráfego de rede proveniente de outros pods no cluster.

Essa vulnerabilidade em si não concede permissões a um invasor para criar um serviço do Kubernetes.

Todos os clusters do Google Kubernetes Engine (GKE) são afetados por essa vulnerabilidade.

O que fazer?

O Kubernetes pode precisar fazer alterações de design incompatíveis com versões anteriores em uma versão futura para lidar com a vulnerabilidade.

Se muitos usuários compartilharem acesso ao cluster com permissões para criar serviços, como em um cluster multilocatário, considere aplicar uma mitigação nesse meio tempo. Por enquanto, a melhor abordagem para a mitigação é restringir o uso de ExternalIPs em um cluster. ExternalIPs não são um recurso frequentemente usado.

Restrinja o uso de ExternalIPs em um cluster com um dos seguintes métodos:

  1. Use o Anthos Policy Controller ou o Gatekeeper com este modelo de restrição e aplique-o. Exemplo:
    
    # 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. Ou instale um controlador de admissão para impedir o uso de ExternalIPs. O projeto do Kubernetes forneceu um controlador de admissão de amostra para essa tarefa.

Como mencionado no Anúncio do Kubernetes, nenhuma mitigação é fornecida para os serviços do tipo LoadBalancer porque, por padrão, apenas usuários altamente privilegiados e componentes do sistema recebem a permissão container.services.updateStatus que é necessária para fazer uso dessa vulnerabilidade.

Média

Clusters do Anthos no

Descrição Gravidade

O projeto Kubernetes descobriu recentemente uma nova vulnerabilidade de segurança, CVE-2020-8554, que permite que um invasor que conseguiu permissões para criar um serviço do Kubernetes do tipo LoadBalancer ou ClusterIP intercepte o tráfego de rede proveniente de outros pods no cluster.

Essa vulnerabilidade em si não concede permissões a um invasor para criar um serviço do Kubernetes.

Todos os clusters do Anthos no VMware são afetados por essa vulnerabilidade.

O que fazer?

O Kubernetes pode precisar fazer alterações de design incompatíveis com versões anteriores em uma versão futura para lidar com a vulnerabilidade.

Se muitos usuários compartilharem acesso ao cluster com permissões para criar serviços, como em um cluster multilocatário, considere aplicar uma mitigação nesse meio tempo. Por enquanto, a melhor abordagem para a mitigação é restringir o uso de ExternalIPs em um cluster. ExternalIPs não são um recurso frequentemente usado.

Restrinja o uso de ExternalIPs em um cluster com um dos seguintes métodos:

  1. Use o Anthos Policy Controller ou o Gatekeeper com este modelo de restrição e aplique-o. Exemplo:
    
    # 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. Ou instale um controlador de admissão para impedir o uso de ExternalIPs. O projeto do Kubernetes forneceu um controlador de admissão de amostra para essa tarefa.

Como mencionado no Anúncio do Kubernetes, nenhuma mitigação é fornecida para os serviços do tipo LoadBalancer porque, por padrão, apenas usuários altamente privilegiados e componentes do sistema recebem a permissão container.services.updateStatus que é necessária para fazer uso dessa vulnerabilidade.

Média

Clusters do Anthos no

Descrição Gravidade

O projeto Kubernetes descobriu recentemente uma nova vulnerabilidade de segurança, CVE-2020-8554, que permite que um invasor que conseguiu permissões para criar um serviço do Kubernetes do tipo LoadBalancer ou ClusterIP intercepte o tráfego de rede proveniente de outros pods no cluster.

Essa vulnerabilidade em si não concede permissões a um invasor para criar um serviço do Kubernetes.

Todos os clusters do Anthos na AWS são afetados por essa vulnerabilidade.

O que fazer?

O Kubernetes pode precisar fazer alterações de design incompatíveis com versões anteriores em uma versão futura para lidar com a vulnerabilidade.

Se muitos usuários compartilharem acesso ao cluster com permissões para criar serviços, como em um cluster multilocatário, considere aplicar uma mitigação nesse meio tempo. Por enquanto, a melhor abordagem para a mitigação é restringir o uso de ExternalIPs em um cluster. ExternalIPs não são um recurso frequentemente usado.

Restrinja o uso de ExternalIPs em um cluster com um dos seguintes métodos:

  1. Use o Anthos Policy Controller ou o Gatekeeper com este modelo de restrição e aplique-o. Exemplo:
    
    # 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. Ou instale um controlador de admissão para impedir o uso de ExternalIPs. O projeto do Kubernetes forneceu um controlador de admissão de amostra para essa tarefa.

Como mencionado no Anúncio do Kubernetes, nenhuma mitigação é fornecida para os serviços do tipo LoadBalancer porque, por padrão, apenas usuários altamente privilegiados e componentes do sistema recebem a permissão container.services.updateStatus que é necessária para fazer uso dessa vulnerabilidade.

Média

GCP-2020-014

Publicado em: 20/10/2020
Referência: CVE-2020-8563, CVE-2020-8564, CVE-2020-8565, CVE-2020-8566

GKE

Atualizado em: 20/10/2020

Descrição Gravidade

Recentemente, o projeto do Kubernetes descobriu vários problemas que permitem a exposição de dados secretos quando as opções de registro detalhado estão ativadas. Os problemas são:

  • CVE-2020-8563: vazamentos de secret em registros para o provedor vSphere kube-controller-manager.
  • CVE-2020-8564: os secrets de configuração do Docker vazaram quando o arquivo estava malformado e com logLevel >= 4.
  • CVE-2020-8565: correção incompleta para CVE-2019-11250 no Kubernetes possibilita o vazamento de token nos registros com logLevel >= 9. Descoberto pela segurança do GKE.
  • CVE-2020-8566: adminSecrets do Ceph RBD expostos nos registros com logLevel >= 4.

O GKE não é afetado.

O que fazer?

Nenhuma outra ação é necessária devido aos níveis de registro detalhado padrão do GKE.

Nenhum

Clusters do Anthos no

Atualizado em: 10/10/2020

Descrição Gravidade

Recentemente, o projeto do Kubernetes descobriu vários problemas que permitem a exposição de dados secretos quando as opções de registro detalhado estão ativadas. Os problemas são:

  • CVE-2020-8563: vazamentos de secret em registros para o provedor vSphere kube-controller-manager.
  • CVE-2020-8564: os secrets de configuração do Docker vazaram quando o arquivo estava malformado e com logLevel >= 4.
  • CVE-2020-8565: correção incompleta para CVE-2019-11250 no Kubernetes possibilita o vazamento de token nos registros com logLevel >= 9. Descoberto pela segurança do GKE.
  • CVE-2020-8566: adminSecrets do Ceph RBD expostos nos registros com logLevel >= 4.

Os clusters do Anthos no VMware não são afetados.

O que fazer?

Nenhuma outra ação é necessária devido aos níveis de registro detalhado padrão do GKE.

Nenhum

Clusters do Anthos no

Atualizado em: 20/10/2020

Descrição Gravidade

Recentemente, o projeto do Kubernetes descobriu vários problemas que permitem a exposição de dados secretos quando as opções de registro detalhado estão ativadas. Os problemas são:

  • CVE-2020-8563: vazamentos de secret em registros para o provedor vSphere kube-controller-manager.
  • CVE-2020-8564: os secrets de configuração do Docker vazaram quando o arquivo estava malformado e com logLevel >= 4.
  • CVE-2020-8565: correção incompleta para CVE-2019-11250 no Kubernetes possibilita o vazamento de token nos registros com logLevel >= 9. Descoberto pela segurança do GKE.
  • CVE-2020-8566: adminSecrets do Ceph RBD expostos nos registros com logLevel >= 4.

Os clusters do Anthos na AWS não são afetados.

O que fazer?

Nenhuma outra ação é necessária devido aos níveis de registro detalhado padrão do GKE.

Nenhum

GCP-2020-012

Publicado em: 14/09/2020
Referência: CVE-2020-14386

GKE

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no kernel do Linux, descrita em CVE-2020-14386, que permite que os escapes de contêineres recebam privilégios raiz no nó do host.

Essa vulnerabilidade afeta todos os nós do GKE. Os pods em execução no GKE Sandbox não são afetados por essa vulnerabilidade.

O que fazer?

Para corrigir essa vulnerabilidade, faça upgrade do plano de controle e, depois, faça upgrade dos nós para uma das versões com patch listadas abaixo:

  • 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

O uso dessa vulnerabilidade requer CAP_NET_RAW, mas poucos ontêineres geralmente exigem CAP_NET_RAW. Este e outros recursos avançados precisam ser bloqueados por padrão usando PodSecurityPolicy ou o Policy Controller:

Reduza a capacidade de CAP_NET_RAW dos contêineres com um dos seguintes métodos:

  • Aplique o bloqueio desses recursos com PodSecurityPolicy, por exemplo:
    
        # 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 usando o Policy Controller ou Gatekeeper para aplicar este modelo de restrição. Por exemplo:
    
        # 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 ao atualizar as especificações do 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
.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2020-14386, que permite que os contêineres com CAP_NET_RAW gravem de 1 a 10 bytes de memória do kernel. Isso também permite fazer o escape do contêiner e receber privilégios de raiz no nó do host. Isso é classificado como uma vulnerabilidade de alta gravidade.

Alto

Clusters do Anthos no

Atualizado em: 17/09/2020

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no kernel do Linux, descrita em CVE-2020-14386, que permite que os escapes de contêineres recebam privilégios raiz no nó do host.

Todos os clusters do Anthos em nós da VMware são afetados.

O que fazer?

Para corrigir essa vulnerabilidade, faça upgrade do cluster para uma versão com patch. As próximas versões do {gke_on_prem_name}} conterão a correção da vulnerabilidade, e este boletim será atualizado quando elas estiverem disponíveis:

  • Clusters do Anthos no VMware 1.4.3, já estão disponíveis.
  • Os clusters do Anthos no VMware 1.3.4 já estão disponíveis.

O uso dessa vulnerabilidade requer CAP_NET_RAW, mas poucos ontêineres geralmente exigem CAP_NET_RAW. Este e outros recursos avançados precisam ser bloqueados por padrão usando PodSecurityPolicy ou o Policy Controller:

Reduza a capacidade de CAP_NET_RAW dos contêineres com um dos seguintes métodos:

  • Aplique o bloqueio desses recursos com PodSecurityPolicy, por exemplo:
    
        # 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 usando o Policy Controller ou Gatekeeper para aplicar este modelo de restrição. Por exemplo:
    
        # 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 ao atualizar as especificações do 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

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2020-14386, que permite que os contêineres com CAP_NET_RAW gravem de 1 a 10 bytes de memória do kernel. Isso também permite fazer o escape do contêiner e receber privilégios de raiz no nó do host. Isso é classificado como uma vulnerabilidade de alta gravidade.

Alto

Clusters do Anthos no

Atualizado em: 13/10/2020

Descrição Gravidade

Uma vulnerabilidade foi descoberta recentemente no kernel do Linux, descrita em CVE-2020-14386, que permite que os escapes de contêineres recebam privilégios raiz no nó do host.

Todos os nós de clusters do Anthos na AWS são afetados.

O que fazer?

Para corrigir essa vulnerabilidade, faça upgrade do serviço de gerenciamento e dos clusters do usuário para uma versão com patch. As próximas versões de clusters do Anthos na AWS ou mais recentes incluirão a correção dessa vulnerabilidade, e este boletim será atualizado quando elas estiverem disponíveis:

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

Reduza a capacidade de CAP_NET_RAW dos contêineres com um dos seguintes métodos:

  • Aplique o bloqueio desses recursos com PodSecurityPolicy, por exemplo:
    
        # 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 usando o Policy Controller ou Gatekeeper para aplicar este modelo de restrição. Por exemplo:
    
        # 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 ao atualizar as especificações do 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

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2020-14386, que permite que os contêineres com CAP_NET_RAW gravem de 1 a 10 bytes de memória do kernel. Isso também permite fazer o escape do contêiner e receber privilégios de raiz no nó do host. Isso é classificado como uma vulnerabilidade de alta gravidade.

Alto

GCP-2020-011

Publicado em: 2020-07-24
Referência: CVE-2020-8558

GKE

Descrição Gravidade

Uma vulnerabilidade de rede, CVE-2020-8558 (em inglês), foi descoberta recentemente no Kubernetes. Às vezes, os serviços se comunicam com outros aplicativos em execução no mesmo pod usando a interface de loopback local (127.0.0.1). Essa vulnerabilidade permite que um invasor com acesso à rede do cluster envie tráfego para a interface de loopback de pods e nós adjacentes. Os serviços que dependem da interface de loopback e não são acessados fora do pod podem ser explorados.

A exploração dessa vulnerabilidade nos clusters do GKE requer que um invasor tenha privilégios de administrador de rede no Google Cloud que hospede a VPC do cluster. Por si só, essa vulnerabilidade não concede privilégios de administrador de rede a invasores. Por esse motivo, essa vulnerabilidade recebeu uma gravidade baixa no GKE.

O que fazer?

Para corrigir essa vulnerabilidade, faça upgrade dos pools de nós do cluster para as seguintes versões do GKE (e posteriores):

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

Qual vulnerabilidade é corrigida por esse patch?

Esse patch corrige a seguinte vulnerabilidade: CVE-2020-8558 (em inglês).

Baixa

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade de rede, CVE-2020-8558 (em inglês), foi descoberta recentemente no Kubernetes. Às vezes, os serviços se comunicam com outros aplicativos em execução no mesmo pod usando a interface de loopback local (127.0.0.1). Essa vulnerabilidade permite que um invasor com acesso à rede do cluster envie tráfego para a interface de loopback de pods e nós adjacentes. Os serviços que dependem da interface de loopback e não são acessados fora do pod podem ser explorados.

O que fazer?

Para corrigir essa vulnerabilidade, faça upgrade do cluster para uma versão com patch. Quando forem lançadas, as versões a seguir dos clusters do Anthos no VMware incluirão a correção dessa vulnerabilidade:

  • Clusters do Anthos no VMware 1.4.1

Qual vulnerabilidade é corrigida por esse patch?

Esse patch corrige a seguinte vulnerabilidade: CVE-2020-8558.

Média

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade de rede, CVE-2020-8558 (em inglês), foi descoberta recentemente no Kubernetes. Às vezes, os serviços se comunicam com outros aplicativos em execução no mesmo pod usando a interface de loopback local (127.0.0.1). Essa vulnerabilidade permite que um invasor com acesso à rede do cluster envie tráfego para a interface de loopback de pods e nós adjacentes. Os serviços que dependem da interface de loopback e não são acessados fora do pod podem ser explorados.

A exploração dessa vulnerabilidade nos clusters de usuário requer que um invasor desative verificações de destino de origem nas instâncias do EC2 no cluster. Isso exige que o invasor tenha permissões do IAM da AWS para ModifyInstanceAttribute ou ModifyNetworkInterfaceAttribute nas instâncias do EC2. Por esse motivo, essa vulnerabilidade recebeu uma gravidade baixa para clusters do Anthos na AWS.

O que fazer?

Para corrigir essa vulnerabilidade, faça upgrade do cluster para uma versão com patch. Quando forem lançadas, as versões a seguir dos clusters do Anthos na AWS incluirão a correção dessa vulnerabilidade:

  • Clusters do Anthos na AWS 1.4.1-gke.17

Qual vulnerabilidade é corrigida por esse patch?

Esse patch corrige a seguinte vulnerabilidade: CVE-2020-8558 (em inglês).

Baixa

GCP-2020-009

Publicado em: 15/07/2020
Referência: CVE-2020-8559

GKE

Descrição Gravidade

Uma vulnerabilidade de escalonamento de privilégios, CVE-2020-8559 (em inglês), foi descoberta recentemente no Kubernetes. Essa vulnerabilidade permite que um invasor que já tenha comprometido um nó execute um comando em qualquer pod do cluster. Dessa forma, o invasor pode usar o nó já afetado para comprometer outros nós e, possivelmente, ler informações ou causar ações destrutivas.

Para que um invasor explore essa vulnerabilidade, é preciso que um nó do cluster já tenha sido comprometido. Essa vulnerabilidade, por si só, não comprometerá os nós do cluster.

O que fazer?

Faça upgrade do cluster para uma versão com patch. Os clusters serão atualizados automaticamente nas próximas semanas, e as versões com patch estarão disponíveis até 19 de julho de 2020 para uma programação acelerada por upgrade manual. As seguintes versões do plano de controle do GKE ou mais recentes contêm a correção dessa vulnerabilidade:

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

Qual vulnerabilidade é corrigida por esse patch?

Esses patches mitigam a vulnerabilidade CVE-2020-8559. Isso é classificado como uma vulnerabilidade média do GKE, porque exige que o invasor tenha informações em primeira mão sobre o cluster, os nós e as cargas de trabalho para aproveitar esse ataque de forma eficaz, além de um nó comprometido. Essa vulnerabilidade sozinha não fornece um nó comprometido a um invasor.

Média

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade de escalonamento de privilégios, CVE-2020-8559 (em inglês), foi descoberta recentemente no Kubernetes. Essa vulnerabilidade permite que um invasor que já tenha comprometido um nó execute um comando em qualquer pod do cluster. Dessa forma, o invasor pode usar o nó já afetado para comprometer outros nós e, possivelmente, ler informações ou causar ações destrutivas.

Para que um invasor explore essa vulnerabilidade, é preciso que um nó do cluster já tenha sido comprometido. Essa vulnerabilidade, por si só, não comprometerá os nós do cluster.

O que fazer?

Faça upgrade do cluster para uma versão com patch. Os seguintes clusters do Anthos nas versões VMware ou posteriores contêm a correção dessa vulnerabilidade:

  • Anthos 1.3.3
  • Anthos 1.4.1

Qual vulnerabilidade é corrigida por esse patch?

Esses patches mitigam a vulnerabilidade CVE-2020-8559. Isso é classificado como uma vulnerabilidade média do GKE, porque exige que o invasor tenha informações em primeira mão sobre o cluster, os nós e as cargas de trabalho para aproveitar esse ataque de forma eficaz, além de um nó comprometido. Essa vulnerabilidade sozinha não fornece um nó comprometido a um invasor.

Média

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade de escalonamento de privilégios, CVE-2020-8559 (em inglês), foi descoberta recentemente no Kubernetes. Essa vulnerabilidade permite que um invasor que já tenha comprometido um nó execute um comando em qualquer pod do cluster. Dessa forma, o invasor pode usar o nó já afetado para comprometer outros nós e, possivelmente, ler informações ou causar ações destrutivas.

Para que um invasor explore essa vulnerabilidade, é preciso que um nó do cluster já tenha sido comprometido. Essa vulnerabilidade, por si só, não comprometerá os nós do cluster.

O que fazer?

Os clusters do Anthos na GA da AWS (1.4.1, disponível no final de julho de 2020) ou mais recentes incluem o patch para essa vulnerabilidade. Se você estiver usando uma versão anterior, faça o download de uma nova versão da ferramenta de linha de comando anthos-gke e recrie seus clusters de gerenciamento e usuário.

Qual vulnerabilidade é corrigida por esse patch?

Esses patches mitigam a vulnerabilidade CVE-2020-8559. Isso é classificado como uma vulnerabilidade média do GKE, porque exige que o invasor tenha informações em primeira mão sobre o cluster, os nós e as cargas de trabalho para aproveitar esse ataque de forma eficaz, além de um nó comprometido. Essa vulnerabilidade sozinha não fornece um nó comprometido a um invasor.

Média

GCP-2020-007

Publicado em: 01/06/2020
Referência: CVE-2020-8555

GKE

Descrição Gravidade

A vulnerabilidade de falsificação de solicitação do lado do servidor (SSRF, na sigla em inglês) CVE-2020-8555 foi descoberta recentemente no Kubernetes. Ela permite que determinados usuários autorizados vazem até 500 bytes de informações confidenciais da rede do host do plano de controle. O plano de controle do Google Kubernetes Engine (GKE) usa os controladores do Kubernetes e, portanto, foi afetado por essa vulnerabilidade. Recomendamos que você faça o upgrade do plano de controle para a última versão do patch, como detalhamos a seguir. Não é necessário fazer upgrade do nó.

O que fazer?

Para quase todos os clientes, nenhuma ação é necessária. A grande maioria dos clusters já executa uma versão com o patch. As seguintes versões do GKE ou superiores contêm a solução para essa vulnerabilidade:
  • 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

Os clusters que usam canais de lançamento já estão nas versões do plano de controle com a mitigação.

Qual vulnerabilidade é corrigida pelo patch?

Esses patches mitigam a vulnerabilidade CVE-2020-8555. Ela é classificada como uma vulnerabilidade de gravidade média para o GKE, porque era difícil explorá-la já que havia várias medidas de aumento de proteção do plano de controle.

Um invasor com permissões para criar um pod com determinados tipos de volume integrado (GlusterFS, Quobyte, StorageFS e ScaleIO) ou permissões para criar um StorageClass pode fazer com que kube-controller-manager crie solicitações GET ou POST sem um corpo de solicitação controlado pelo invasor na rede do host do mestre. Esses tipos de volume raramente são usados no GKE, então uma nova utilização deles pode ser um sinal útil para detectar problemas.

Combinado com um meio de vazar os resultados de GET/POST para o invasor, como por meio de registros, essa vulnerabilidade pode levar à divulgação de informações confidenciais. Atualizamos os drivers de armazenamento em questão para remover a possibilidade desses vazamentos acontecerem.

Média

Clusters do Anthos no

Descrição Gravidade

A vulnerabilidade de falsificação de solicitação do lado do servidor (SSRF, na sigla em inglês) CVE-2020-8555 foi descoberta recentemente no Kubernetes. Ela permite que determinados usuários autorizados vazem até 500 bytes de informações confidenciais da rede do host do plano de controle. O plano de controle do Google Kubernetes Engine (GKE) usa os controladores do Kubernetes e, portanto, foi afetado por essa vulnerabilidade. Recomendamos que você faça o upgrade do plano de controle para a versão mais recente do patch, conforme detalhado abaixo. Não é necessário fazer upgrade do nó.

O que fazer?

Os seguintes clusters do Anthos nas versões do VMware (GKE On-Prem) ou mais recente contêm a correção desta vulnerabilidade:

  • Anthos 1.3.0

Se você estiver usando uma versão anterior, faça upgrade do cluster atual para uma versão que contenha a correção.

Qual vulnerabilidade é corrigida por esse patch?

Esses patches mitigam a vulnerabilidade CVE-2020-8555. Ela é classificada como uma vulnerabilidade de gravidade média para o GKE, porque era difícil explorá-la já que havia várias medidas de aumento de proteção do plano de controle.

Um invasor com permissões para criar um pod com determinados tipos de volume integrado (GlusterFS, Quobyte, StorageFS e ScaleIO) ou permissões para criar um StorageClass pode fazer com que kube-controller-manager crie solicitações GET ou POST sem um corpo de solicitação controlado pelo invasor na rede do host do mestre. Esses tipos de volume raramente são usados no GKE, então uma nova utilização deles pode ser um sinal útil para detectar problemas.

Combinado com um meio de vazar os resultados de GET/POST para o invasor, como por meio de registros, essa vulnerabilidade pode levar à divulgação de informações confidenciais. Atualizamos os drivers de armazenamento em questão para remover a possibilidade desses vazamentos acontecerem.

Média

Clusters do Anthos no

Descrição Gravidade

A vulnerabilidade de falsificação de solicitação do lado do servidor (SSRF, na sigla em inglês) CVE-2020-8555 foi descoberta recentemente no Kubernetes. Ela permite que determinados usuários autorizados vazem até 500 bytes de informações confidenciais da rede do host do plano de controle. O plano de controle do Google Kubernetes Engine (GKE) usa os controladores do Kubernetes e, portanto, foi afetado por essa vulnerabilidade. Recomendamos que você faça o upgrade do plano de controle para a versão mais recente do patch, conforme detalhado abaixo. Não é necessário fazer upgrade do nó.

O que fazer?

Os clusters do Anthos na AWS (GKE na AWS) v0.2.0 ou mais recentes já incluem o patch para essa vulnerabilidade. Se você estiver usando uma versão anterior, faça o download de uma nova versão da ferramenta de linha de comando anthos-gke e recrie seus clusters de gerenciamento e usuário.

Qual vulnerabilidade é corrigida por esse patch?

Esses patches mitigam a vulnerabilidade CVE-2020-8555. Ela é classificada como uma vulnerabilidade de gravidade média para o GKE, porque era difícil explorá-la já que havia várias medidas de aumento de proteção do plano de controle.

Um invasor com permissões para criar um pod com determinados tipos de volume integrado (GlusterFS, Quobyte, StorageFS e ScaleIO) ou permissões para criar um StorageClass pode fazer com que kube-controller-manager crie solicitações GET ou POST sem um corpo de solicitação controlado pelo invasor na rede do host do mestre. Esses tipos de volume raramente são usados no GKE, então uma nova utilização deles pode ser um sinal útil para detectar problemas.

Combinado com um meio de vazar os resultados de GET/POST para o invasor, como por meio de registros, essa vulnerabilidade pode levar à divulgação de informações confidenciais. Atualizamos os drivers de armazenamento em questão para remover a possibilidade desses vazamentos acontecerem.

Média

GCP-2020-006

Publicado em: 01/062020
Referência: problema 91507 do Kubernetes

GKE

Descrição Gravidade

O Kubernetes divulgou uma vulnerabilidade que permite que um contêiner com privilégios redirecione o tráfego do nó para outro contêiner. O tráfego mútuo TLS/SSH, como entre o kubelet e o servidor da API, ou o tráfego de aplicativos que usam mTLS não pode ser lidos ou modificado por essa invasão. Todos os nós do Google Kubernetes Engine (GKE) foram afetados por essa vulnerabilidade. Recomendamos que você faça o upgrade para a versão mais recente do patch, conforme detalhado a seguir.

O que fazer?

Para mitigar essa vulnerabilidade, faça o upgrade do seu plano de controle e dos seus nós para uma das versões com patch listadas a seguir. Os clusters nos canais de lançamento já estão executando uma versão com patch no plano de controle e nos nós:
  • 1.14.10-gke.36
  • 1.15.11-gke.15
  • 1.16.8-gke.15

Em geral, pouquíssimos contêineres exigem CAP_NET_RAW. Essa e outras capacidades poderosas deveriam estar bloqueadas por padrão pela PodSecurityPolicy ou o Policy Controller do Anthos:

Reduza a capacidade de CAP_NET_RAW dos contêineres com um dos seguintes métodos:

  • Aplique o bloqueio desses recursos com PodSecurityPolicy, por exemplo:
    
        # 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 usando o Policy Controller ou Gatekeeper para aplicar este modelo de restrição. Por exemplo:
    
        # 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 ao atualizar as especificações do 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

Qual vulnerabilidade é corrigida por esse patch?

O patch mitiga a seguinte vulnerabilidade:

A vulnerabilidade descrita na capacidade CAP_NET_RAW do problema 91507 do Kubernetes (que está incluída no conjunto de capacidades de contêiner padrão) que envolve configurar de forma mal-intencionada a pilha do IPv6 no nó e redirecionar o tráfego do nó para o contêiner controlado pelo invasor. Isso permite que o invasor intercepte/modifique o tráfego que se origina do nó ou se destina a ele. O tráfego mútuo TLS/SSH, como entre o kubelet e o servidor da API, ou o tráfego de aplicativos que usam mTLS não pode ser lido ou modificado por essa invasão.

Média

Clusters do Anthos no

Descrição Gravidade

O Kubernetes divulgou uma vulnerabilidade que permite que um contêiner com privilégios redirecione o tráfego do nó para outro contêiner. O tráfego mútuo TLS/SSH, como entre o kubelet e o servidor da API, ou o tráfego de aplicativos que usam mTLS não pode ser lidos ou modificado por essa invasão. Todos os nós do Google Kubernetes Engine (GKE) foram afetados por essa vulnerabilidade, e recomendamos que você faça o upgrade para a versão mais recente do patch, como detalhamos a seguir.

O que fazer?

Para atenuar esta vulnerabilidade dos clusters do Anthos no VMware (GKE On-Prem), faça o upgrade dos clusters para a versão mais recente ou mais recente:
  • Anthos 1.3.2

Em geral, pouquíssimos contêineres exigem CAP_NET_RAW. Esse e outros recursos avançados precisam ser bloqueados, por padrão, usando o Anthos Policy Controller ou atualizando as especificações de pod:

Reduza a capacidade de CAP_NET_RAW dos contêineres com um dos seguintes métodos:

  • Aplique o bloqueio desses recursos com PodSecurityPolicy, por exemplo:
    
        # 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 usando o Policy Controller ou Gatekeeper para aplicar este modelo de restrição. Por exemplo:
    
        # 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 ao atualizar as especificações do 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

Qual vulnerabilidade é corrigida por esse patch?

O patch mitiga a seguinte vulnerabilidade:

A vulnerabilidade descrita na capacidade CAP_NET_RAW do problema 91507 do Kubernetes (que está incluída no conjunto de capacidades de contêiner padrão) que envolve configurar de forma mal-intencionada a pilha do IPv6 no nó e redirecionar o tráfego do nó para o contêiner controlado pelo invasor. Isso permite que o invasor intercepte/modifique o tráfego que se origina do nó ou se destina a ele. O tráfego mútuo TLS/SSH, como entre o kubelet e o servidor da API, ou o tráfego de aplicativos que usam mTLS não pode ser lido ou modificado por essa invasão.

Média

Clusters do Anthos no

Descrição Gravidade

O Kubernetes divulgou uma vulnerabilidade que permite que um contêiner com privilégios redirecione o tráfego do nó para outro contêiner. O tráfego mútuo TLS/SSH, como entre o kubelet e o servidor da API, ou o tráfego de aplicativos que usam mTLS não pode ser lidos ou modificado por essa invasão. Todos os nós do Google Kubernetes Engine (GKE) foram afetados por essa vulnerabilidade, e recomendamos que você faça o upgrade para a versão mais recente do patch, como detalhamos a seguir.

O que fazer?

Faça o download da ferramenta de linha de comando anthos-gke com a seguinte versão ou mais recente e crie novamente os clusters de gerenciamento e usuário:

  • aws-0.2.1-gke.7

Em geral, pouquíssimos contêineres exigem CAP_NET_RAW. Esse e outros recursos avançados precisam ser bloqueados, por padrão, usando o Anthos Policy Controller ou atualizando as especificações de pod:

Reduza a capacidade de CAP_NET_RAW dos contêineres com um dos seguintes métodos:

  • Aplique o bloqueio desses recursos com PodSecurityPolicy, por exemplo:
    
        # 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 usando o Policy Controller ou Gatekeeper para aplicar este modelo de restrição. Por exemplo:
    
        # 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 ao atualizar as especificações do 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

Qual vulnerabilidade é corrigida por esse patch?

O patch mitiga a seguinte vulnerabilidade:

A vulnerabilidade descrita na capacidade CAP_NET_RAW do problema 91507 do Kubernetes (que está incluída no conjunto de capacidades de contêiner padrão) que envolve configurar de forma mal-intencionada a pilha do IPv6 no nó e redirecionar o tráfego do nó para o contêiner controlado pelo invasor. Isso permite que o invasor intercepte/modifique o tráfego que se origina do nó ou se destina a ele. O tráfego mútuo TLS/SSH, como entre o kubelet e o servidor da API, ou o tráfego de aplicativos que usam mTLS não pode ser lido ou modificado por essa invasão.

Média

GCP-2020-005

Publicado em: 07/052020
Atualizado em: 07/05/2020
Referência: CVE-2020-8835

GKE

Descrição Gravidade

Uma vulnerabilidade foi recentemente descoberta no kernel do Linux, descrita em CVE-2020-8835 (em inglês), permitindo que o escape de contêiner receba privilégios de raiz no nó do host.

Os nós do Ubuntu do Google Kubernetes Engine executando a versão 1.16 ou 1.17 do GKE foram afetados por essa vulnerabilidade. Recomendamos que você faça upgrade para a versão de patch mais recente assim que possível, conforme detalhado abaixo.

Os nós executando o SO otimizado para contêineres não foram afetados. Os nós em execução nos clusters do Anthos no VMware não foram afetados.

O que fazer?

Para a maioria dos clientes, nenhuma outra ação é necessária. Apenas os nós executando o Ubuntu na versão 1.16 ou 1.17 do GKE foram afetados.

Para fazer upgrade dos seus nós, primeiro você precisa fazer o upgrade do mestre para a versão mais recente. Esse patch será disponibilizado nestas versões do Kubernetes: 1.16.8-gke.12, 1.17.4-gke.10 e lançamentos posteriores. Acompanhe a disponibilidade dos patches nas notas de lançamento.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A CVE-2020-8835 (em inglês) descreve uma vulnerabilidade na versão 5.5.0 e posteriores do kernel do Linux, que permite que um contêiner mal-intencionado (com interação mínima do usuário na forma de um exec) leia e grave na memória do kernel e consiga a execução do código no nível da raiz do nó do host. Isso é classificado como uma vulnerabilidade de alto nível de gravidade.

Alto

GCP-2020-004

Publicado em: 07/05/2020
Atualizado em: 07-05-2020
Referência: CVE-2019-11254

Clusters do Anthos no

Descrição Gravidade

Uma vulnerabilidade foi descoberta no Kubernetes recentemente, descrita em CVE-2019-11254 (em inglês). Ela permite que qualquer usuário autorizado a fazer solicitações POST execute um ataque remoto de negação de serviço em um servidor da API Kubernetes. O Comitê de Segurança de Produto (PSC, na sigla em inglês) do Kubernetes divulgou mais informações sobre essa vulnerabilidade. Para saber mais, acesse-as aqui (em inglês).

É possível mitigar essa vulnerabilidade limitando os clientes que têm acesso à rede dos servidores da API Kubernetes.

O que fazer?

Recomendamos fazer upgrade de seus clusters para corrigir versões que contenham a correção dessa vulnerabilidade assim que estiverem disponíveis.

Veja abaixo as versões de patch que solucionam o problema:

  • Anthos 1.3.0, que executa o Kubernetes versão 1.15.7-gke.32

Quais vulnerabilidades são corrigidas por esse patch?

A de negação de serviço (DoS) a seguir:

CVE-2019-11254 (em inglês).

Média

GCP-2020-003

Publicado em: 31/03/2020
Atualizado em: 31/03/2020
Referência: CVE-2019-11254

GKE

Descrição Gravidade

Uma vulnerabilidade foi descoberta no Kubernetes recentemente, descrita em CVE-2019-11254 (em inglês). Ela permite que qualquer usuário autorizado a fazer solicitações POST execute um ataque remoto de negação de serviço em um servidor da API Kubernetes. O Comitê de Segurança de Produto (PSC, na sigla em inglês) do Kubernetes divulgou mais informações sobre essa vulnerabilidade. Para saber mais, acesse-as aqui (em inglês).

Os clusters do GKE que usam redes mestras autorizadas e clusters privados sem endpoint público reduzem essa vulnerabilidade.

O que fazer?

Recomendamos que você faça o upgrade do seu cluster para uma versão de patch com a correção da vulnerabilidade.

Veja abaixo as versões de patch que solucionam o problema:

  • 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

Quais vulnerabilidades são corrigidas por esse patch?

A de negação de serviço (DoS) a seguir:

CVE-2019-11254 (em inglês).

Média

GCP-2020-002

Publicado em: 23/03/2020
Atualizado em: 23/03/2020
Referência: CVE-2020-8551, CVE-2020-8552

GKE

Descrição Gravidade

O Kubernetes divulgou duas vulnerabilidades de negação de serviço (em inglês), uma com impacto no servidor de API e outra no Kubelets. Para mais detalhes, veja os seguintes problemas do Kubernetes: 89377 e 89378 (ambos em inglês).

O que fazer?

Todos os usuários do GKE estão protegidos contra a CVE-2020-8551, a menos que usuários que não sejam de confiança possam enviar solicitações dentro da rede interna dos clusters. Além disso, o uso das redes mestras autorizadas reduz a CVE-2020-8552.

Quando essas vulnerabilidades serão corrigidas?

Os patches para a CVE-2020-8551 exigem um upgrade de nó. Abaixo, as versões de patch que mitigam o problema:

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

Os patches para a CVE-2020-8552 exigem o upgrade de um mestre. Abaixo, as versões de patch que mitigam o problema:

  • 1.14.10-gke.32
  • 1.15.10-gke.*
  • 1.16.7-gke.*
Média

21 de janeiro de 2020

Publicado em: 21/01/2020
Atualizado em: 24/01/2020
Referência: CVE-2019-11254

GKE

Descrição Gravidade

Atualização de 24/01/2020: o processo de disponibilização de versões com patch está sendo realizado e será concluído em 25 de janeiro de 2020.


A Microsoft divulgou uma vulnerabilidade na Windows CryptoAPI e em sua validação de assinaturas de curva elíptica. Para mais informações, consulte o anúncio da Microsoft.

O que fazer?

Para a maioria dos clientes, nenhuma outra ação é necessária. Somente os nós com Windows Server em execução são afetados.

Nesse caso, para reduzir a vulnerabilidade, é necessário atualizar os nós e as cargas de trabalho em contêineres executadas neles para as versões com patch.

Para atualizar os contêineres:

É necessário recriá-los. Para isso, use as imagens de contêiner de base mais recentes da Microsoft selecionando uma tag de servercore ou nanoserver (páginas em inglês) que tenha o valor "1/14/2020" ou posterior em "LastUpdated Time".

Para atualizar os nós:

O processo de disponibilização de versões com patch está sendo realizado e será concluído em 24 de janeiro de 2020.

Faça o upgrade dos nós para uma versão de patch do GKE ou use o Windows Update para implantar manualmente o patch mais recente do Windows a qualquer momento.

Abaixo, as versões de patch que incluem a mitigação:

  • 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

Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz as vulnerabilidades a seguir:

CVE-2020-0601 (em inglês): também conhecida como Vulnerabilidade de spoofing da Windows CryptoAPI. Usada para fazer executáveis maliciosos parecerem confiáveis ou permitir que o invasor realize ataques "man-in-the-middle" e descriptografe informações confidenciais nas conexões TLS com o software afetado.

Pontuação base do NVD: 8,1 (alta)

Boletins de segurança arquivados

Para boletins de segurança anteriores a 2020, consulte o Arquivo de boletins de segurança.