Arquivo de boletins de segurança

Esta página contém um arquivo histórico de todos os boletins de segurança anteriores a 2020 relativos aos seguintes produtos:

Para ver os boletins de segurança mais recentes, consulte a página Boletins de segurança.

Boletins de segurança do GKE

14 de novembro de 2019

Publicação: 14/11/2019
Atualizado em: 14/11/2019
Descrição Gravidade Observações

O Kubernetes divulgou um problema de segurança nos arquivos secundários external-provisioner, external-snapshotter e external-resizer do kubernetes-csi que impacta a maioria das versões dos arquivos secundários incluídos nos drivers da Container Storage Interface (CSI) [páginas em inglês]. Para ver mais detalhes, consulte a divulgação do Kubernetes.

O que fazer?
Essa vulnerabilidade não afeta nenhum componente do GKE gerenciado. Você pode ser afetado se gerenciar seus próprios drivers CSI em clusters Alfa do GKE executando o GKE versão 1.12 ou mais recente. Se você for afetado, verifique as instruções de upgrade com seu distribuidor de drivers CSI.

Quais vulnerabilidades são corrigidas por esse patch?
CVE-2019-11255: é uma vulnerabilidade nos arquivos secundários kubernetes-csiexternal-provisioner, external-snapshotter e external-resizer que possibilita acesso ou mutação não autorizados dos dados de volumes. Isso impacta a maioria das versões de arquivos secundários incluídos em drivers CSI.

Média

CVE-2019-11255

12 de novembro de 2019

Publicação: 12/11/2019
Atualizado em: 12/11/2019
Descrição Gravidade Observações

A Intel divulgou CVEs que potencialmente permitem interações entre a execução especulativa e o estado microarquitetônico para expor dados. Para ver mais detalhes, consulte o anúncio da Intel (em inglês).

A infraestrutura de host na qual o Kubernetes Engine é executado isola as cargas de trabalho do cliente. A não ser que você esteja executando código não confiável nos seus próprios clusters GKE multilocatários e utilizando nós N2, M2 ou C2, nenhuma ação extra é necessária. Para instâncias do GKE em nós N1, nenhuma outra ação é necessária.

Se estiver executando o GKE no VMware, a exposição dependerá do hardware. Compare sua infraestrutura com o anúncio da Intel.

O que fazer?

Você só será impactado se estiver usando pools de nós com nós N2, M2 ou C2 e esses nós estiverem executando código não confiável dentro de seus próprios clusters GKE multilocatário.

Reiniciar seus nós aplica o patch. A forma mais fácil de reiniciar todos os nós em seu pool de nós é usar a operação de upgrade para forçar uma reinicialização em todos os pools de nós afetados.

Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz as vulnerabilidades a seguir:

CVE-2019-11135: também é chamada de "TSX Async Abort" (TAA). Fornece outra via para a exfiltração de dados, usando as mesmas estruturas da microarquitetura de dados exploradas pela Amostragem de dados de microarquitetura (MDS, na sigla em inglês).

CVE-2018-12207: vulnerabilidade de negação de serviço (DoS) que afeta hosts de máquina virtual, permitindo que um convidado mal-intencionado cause uma falha em um host desprotegido. Também é chamada de "Erro de verificação de máquina na alteração do tamanho da página". Ela não afeta o GKE.

Médio

CVE-2019-11135
CVE-2018-12207

22 de outubro de 2019

Publicação: 22/10/2019
Atualizado em: 22/10/2019
Descrição Gravidade Observações

Uma vulnerabilidade foi descoberta recentemente na Linguagem de programação Go, descrita na CVE-2019-16276. Ela tem potencial para impactar configurações do Kubernetes usando um proxy de autenticação. Para ver mais detalhes, consulte o anúncio do Kubernetes.

O Kubernetes Engine não permite a configuração de um proxy de autenticação. Portanto, não é afetado por essa vulnerabilidade.

Nenhuma

CVE-2019-16276

16 de outubro de 2019

Publicação: 16/10/2019
Atualizado em: 24/10/2019
Descrição Gravidade Observações

Atualização de 24/10/2019: agora, versões em patch estão disponíveis em todas as zonas.

Uma vulnerabilidade foi descoberta no Kubernetes recentemente, descrita na CVE-2019-11253. Ela possibilita 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 informações adicionais sobre essa vulnerabilidade, que podem ser encontradas aqui.

Clusters do GKE que usam Redes de instâncias mestres autorizadas e Clusters privados sem endpoint público reduzem essa vulnerabilidade.

O que devo fazer?

Recomendamos fazer upgrade do cluster para uma versão de patch com a correção assim que ela estiver disponível. Esperamos que esteja disponível em todas as zonas com a versão para o GKE prevista para a semana de 14 de outubro.

As versões do patch com a redução são:

  • 1.12.10-gke.15
  • 1.13.11-gke.5
  • 1.14.7-gke.10
  • 1.15.4-gke.15
Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz as vulnerabilidades a seguir:

A CVE-2019-11253 é uma vulnerabilidade de negação de serviço (DoS).

Alta

CVE-2019-11253

16 de setembro de 2019

Publicação: 16/09/2019
Atualizado em: 16/10/2019
Descrição Gravidade Observações

Este boletim já foi atualizado desde a publicação original.

As vulnerabilidades de segurança CVE-2019-9512 e CVE-2019-9514 (páginas em inglês) na linguagem de programação Go são vulnerabilidades de negação de serviço (DoS) que foram recentemente descobertas. No GKE, elas possibilitariam que um usuário criasse solicitações mal-intencionadas que consomem uma quantidade excessiva de CPU no servidor da API Kubernetes, potencialmente reduzindo a disponibilidade do plano de controle do cluster. Para mais detalhes, consulte a divulgação da Linguagem de programação Go.

O que devo fazer?

Recomendamos fazer upgrade do cluster para a versão de patch mais recente com a mitigação dessa vulnerabilidade assim que ela estiver disponível. Esperamos que ela esteja disponível em todas as zonas com o próximo lançamento do GKE, de acordo com a programação de lançamento.

As versões do patch com a redução são:

  • Atualização de 16 de outubro de 2019: 1.12.10-gke.15
  • 1.13.10-gke.0
  • 1.14.6-gke.1
Qual vulnerabilidade é corrigida por esse patch?

O patch reduz as vulnerabilidades a seguir:

A CVE-2019-9512 e a CVE-2019-9514 são vulnerabilidades de negação de serviço (DoS).

Alta

CVE-2019-9512
CVE-2019-9514

5 de setembro de 2019

Publicação: 05/09/2019
Atualizado em: 05/09/2019

O boletim sobre a correção da vulnerabilidade documentada no boletim de 31 de maio de 2019 foi atualizado.

22 de agosto de 2019

Publicação: 22/08/2019
Atualizado em: 22/08/2019

O boletim de 5 de agosto de 2019 foi atualizado. A correção da vulnerabilidade documentada no boletim anterior está disponível.

8 de agosto de 2019

Publicação: 08/08/2019
Atualizado em: 08/08/2019

O boletim de 5 de agosto de 2019 foi atualizado. Esperamos que a correção da vulnerabilidade documentada naquele boletim esteja disponível na próxima versão do GKE.

5 de agosto de 2019

Publicação: 05/08/2019
Atualizado em: 09/08/2019
Descrição Gravidade Observações

Este boletim já foi atualizado desde a publicação original.

Recentemente, o Kubernetes descobriu uma vulnerabilidade, a CVE-2019-11247, que possibilita que instâncias de recursos personalizados com escopo no cluster sejam usadas como se fossem objetos de namespaces existentes em todos os namespaces. Isso significa que contas de usuários e de serviço com permissões apenas do RBAC de nível do namespace podem interagir com recursos personalizados com escopo no cluster. A exploração dessa vulnerabilidade exige que o invasor tenha privilégios para acessar o recurso no namespace.

O que devo fazer?

Recomendamos fazer upgrade do cluster para a versão de patch mais recente com a mitigação dessa vulnerabilidade, assim que ela estiver disponível. Esperamos que ela esteja disponível em todas as zonas com a próxima versão do GKE. As versões de patch com a mitigação são:

  • 1.11.10-gke.6
  • 1.12.9-gke.13
  • 1.13.7-gke.19
  • 1.14.3-gke.10 (Canal rápido)
Qual vulnerabilidade é corrigida por esse patch?

O patch reduz a seguinte vulnerabilidade: CVE-2019-11247.

Médio

CVE-2019-11247

3 de julho de 2019

Publicação: 03/07/2019
Atualizado em: 03/07/2019
Descrição Gravidade Observações

Uma versão de patch de kubectl para tratar da CVE-2019-11246 está disponível agora com a gcloud 253.0.0. Consulte o boletim de segurança de 25 de junho de 2019 para mais informações.

Observação: O patch não está disponível no kubectl 1.11.10.

Alta

CVE-2019-11246

3 de julho de 2019

Publicação: 25/06/2019
Atualizado em: 03/07/2019
Descrição Gravidade Observações
Atualização de 3 de julho de 2019

Quando você fez sua última atualização, os patches para as versões 1.11.9 e 1.11.10 ainda não estavam disponíveis. A 1.11.10-gke.5 foi lançada agora como um upgrade para as duas versões 1.11.

Neste momento, as instâncias mestre do GKE e a infraestrutura do Google que executa o Kubernetes Engine já tiveram patches aplicados a elas e a infraestrutura está protegida dessa vulnerabilidade.

As instâncias mestras da versão 1.11 ficarão obsoletas em breve e estão programadas para fazer upgrade para a 1.12 na semana de 8 de julho de 2019. É possível escolher qualquer uma das ações sugeridas a seguir para aplicar uma versão com patch aos nós:

  • Faça o upgrade do nó para 1.11.10-gke.5 até 8 de julho de 2019. Após essa data, as versões 1.11 começarão a ser removidas da lista de upgrades disponíveis.
  • Ative os upgrades automáticos dos nós 1.11 e permita que seja feito o upgrade deles quando for feito o upgrade das instâncias mestre para 1.12.
  • Faça upgrade manual das instâncias mestre e dos nós para uma versão 1.12 corrigida.

Segue o boletim original de 24 de junho de 2019:

Atualização de 24 de junho de 2019

Às 21h40 UTC de 22/06/2019, disponibilizamos as seguintes versões com patch do Kubernetes. Os mestres com versões 1.11.0 e 1.13.6 do Kubernetes serão atualizados automaticamente para uma versão com patch. Se você não está usando uma versão compatível com esse patch, faça upgrade para uma versão compatível do mestre (listada abaixo) antes de fazer upgrade dos nós.

Devido à gravidade dessas vulnerabilidades, tendo ou não ativado o upgrade automático de nós, é recomendável que você faça upgrade manualmente dos nós e das instâncias mestre para uma dessas versões assim que possível.

As versões em patch:

  • 1.11.8-gke.10
  • 1.12.7-gke.24
  • 1.12.8-gke.10
  • 1.13.6-gke.13

Segue o boletim original de 18 de junho de 2019:

A Netflix divulgou recentemente três vulnerabilidades do TCP nos kernels do Linux:

Essas CVEs são coletivamente denominadas NFLX-2019-001 (em inglês).

Os kernels do Linux sem patch podem ser vulneráveis a ataques de negação de serviço disparados remotamente. Os nós do Google Kubernetes Engine que enviam e recebem tráfego de redes não confiáveis são afetados. É recomendável seguir as etapas de mitigação abaixo para proteger suas cargas de trabalho.

Mestres do Kubernetes

  • As instâncias mestre do Kubernetes que usam Redes autorizadas para limitar o tráfego de redes confiáveis não são afetadas.

  • Os mestres de clusters do GKE, que são gerenciados pelo Google, serão corrigidos automaticamente nos próximos dias. Nenhuma ação do cliente é necessária.

Nós do Kubernetes

Nós que limitam o tráfego a redes confiáveis não são afetados. Um cluster afetado poderá apresentar:

  • Nós protegidos por firewall contra redes não confiáveis ou sem IPs públicos (Clusters privados)
  • Clusters sem serviços públicos do tipo LoadBalancer

O Google está preparando uma mitigação permanente dessas vulnerabilidades que será disponibilizada como uma nova versão de nó. Quando a correção permanente estiver disponível, este boletim será atualizado e todos os clientes do GKE receberão um e-mail.

Até lá, é possível usar um DaemonSet criado para o Kubernetes, que implementa reduções ao modificar a configuração do host iptables.

O que devo fazer?

Aplique o DaemonSet do Kubernetes para todos os nós no cluster executando o comando a seguir. Isso adiciona uma regra iptables às regras iptables existentes no nó para reduzir a vulnerabilidade. Execute o comando uma vez por cluster para cada projeto do Google Cloud. 


kubectl apply -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

Quando uma versão com patch do nó estiver disponível e todos os nós possivelmente afetados tiverem passado por upgrade, será possível remover o DaemonSet usando o comando a seguir. Execute o comando uma vez por cluster para cada projeto do Google Cloud. 


kubectl delete -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml
Alta
Média
Média
 CVE-2019-11477
CVE-2019-11478
CVE-2019-11479

25 de junho de 2019

Descrição Gravidade Observações

Atualização de 03/07/2019: Este patch está disponível no gcloud 253.0.0, para as versões 1.12.9, 1.13.6, 1.14.2 e mais novas do kubectl.

Observação: O patch não está disponível na versão 1.11.10.

Recentemente, o Kubernetes descobriu uma vulnerabilidade, a CVE-2019-11246 (em inglês), que possibilita que um invasor com acesso a uma operação kubectl cp e execução de código dentro de um contêiner modifique arquivos no host. Essa exploração tem potencial para possibilitar que um invasor substitua ou crie um arquivo no sistema de arquivos do host. Para ver mais detalhes, consulte o anúncio do Kubernetes.

Todas as versões da gcloud no Google Kubernetes Engine (GKE) são afetadas por essa vulnerabilidade. É recomendável fazer upgrade para a versão de patch mais recente da gcloud quando ela estiver disponível. Uma futura versão de patch incluirá uma mitigação dessa vulnerabilidade.

O que devo fazer?

Uma versão com patch da kubectl será disponibilizada em um futuro lançamento da gcloud. Também é possível fazer upgrade da kubectl por conta própria.

Acompanhe a disponibilidade desse patch nas notas de versão do gcloud.

Qual vulnerabilidade é corrigida por esse patch?

A vulnerabilidade CVE-2019-11246 possibilita que um invasor com acesso a uma operação kubectl cp e capaz de executar um código dentro de um contêiner modifique arquivos no host. Essa exploração tem potencial para possibilitar que um invasor substitua ou crie um arquivo no sistema de arquivos do host.

Alta

CVE-2019-11246

18 de junho de 2019

Descrição Gravidade Observações

Recentemente, o Docker descobriu uma vulnerabilidade, a CVE-2018-15664 (em inglês), que possibilita que um invasor capaz de executar um código dentro de um contêiner sequestre uma operação docker cp iniciada externamente. Essa exploração tem potencial para possibilitar que um invasor altere o local onde um arquivo está sendo gravado para um local arbitrário no sistema de arquivos do host.

Todos os nós do Google Kubernetes Engine (GKE) nos quais o Docker é executado são afetados por essa vulnerabilidade. É recomendável fazer upgrade para a versão de patch mais recente assim que estiver disponível. Uma futura versão de patch incluirá uma mitigação dessa vulnerabilidade.

Todos os mestres do Google Kubernetes Engine (GKE) anteriores à versão 1.12.7 executam o Docker e são afetados por essa vulnerabilidade. No GKE, os usuários não têm acesso à operação docker cp no mestre. Portanto, o risco dessa vulnerabilidade para mestres do GKE é limitado.

O que devo fazer?

Apenas os nós com o Docker em execução são afetados, e somente quando for emitido um comando docker cp (ou equivalente da API) que possa ser invadido. Espera-se que isso seja bastante incomum em um ambiente do Kubernetes. Nós com o Container-Optimized OS com containerd em execução não são afetados.

Para fazer o upgrade dos nós, primeiro é necessário fazer upgrade do mestre para a versão com patch. Quando o patch estiver disponível, será possível iniciar o upgrade do mestre ou esperar que o Google faça o upgrade automaticamente. O patch estará disponível no Docker 18.09.7, que será incluído em um futuro patch do GKE. Esse patch será disponibilizado apenas para as versões 1.13 e mais recentes do GKE.

Faremos upgrade automático dos mestres do cluster para a versão com patch no ritmo normal de upgrades. Também é possível iniciar o upgrade de um mestre por conta própria depois que a versão com patch estiver disponível.

Este boletim será atualizado com as versões com patch assim que estiverem disponíveis. Acompanhe a disponibilidade desses patches nas notas de lançamento.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2018-15664 possibilita que um invasor capaz de executar um código dentro de um contêiner invada uma operação docker cp iniciada externamente. Essa exploração permite que um invasor altere o local onde um arquivo está sendo gravado para um local arbitrário no sistema de arquivos do host.

Alta

31 de maio de 2019

Descrição Gravidade Observações

Este boletim já foi atualizado desde a publicação original.

Atualização de 2 de agosto de 2019

No momento da publicação do boletim inicial, apenas as versões de 1.13.6-gke.0 a 1.13.6-gke.5 foram impactadas. Devido a uma regressão, todas as versões 1.13.6.x foram afetadas agora. Se você tiver a versão 1.13.6, faça o upgrade para a 1.13.7 o mais rápido possível.

O projeto Kubernetes divulgou a CVE-2019-11245 (em inglês) no kubelet v1.13.6 e v1.14.2. Ela pode fazer os contêineres funcionarem como UID 0 (normalmente associado ao usuário root), mesmo que um usuário diferente seja especificado na imagem do contêiner. Se os contêineres funcionam como um usuário não raiz e você está executando uma versão de nó entre a 1.13.6-gke.0 e a 1.13.6-gke.6, é recomendável configurar RunAsUser em todos os pods no cluster cujos contêineres não deveriam funcionar como UID 0.

Se um valor de USER não raiz for especificado (por exemplo, ao configurar o valor de USER em um Dockerfile), ocorrerá algum comportamento inesperado. Quando um contêiner é executado pela primeira vez em um nó, ele respeita corretamente o UID especificado. Contudo, devido a esse defeito, na segunda execução (e nas subsequentes) o contêiner é executado como UID 0 apesar do UID especificado. Em geral, isso é um privilégio escalonado indesejado e pode levar a um comportamento inesperado do aplicativo.

Como saber se tenho uma versão impactada?

Execute o seguinte comando para listar todos os nós e a versão do kubelet deles: 


kubectl get nodes -o=jsonpath='{range .items[*]}'\
'{.status.nodeInfo.machineID}'\
'{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'

Se o resultado mostrar versões do kubelet listadas abaixo, seus nós foram impactados:

  • v1.13.6
  • v1.14.2
Como saber se minha configuração específica foi afetada?

Se os contêineres funcionam como um usuário não raiz e você está executando uma versão de nó entre a 1.13.6-gke.0 e a 1.13.6-gke.6, você foi impactado exceto nos casos a seguir:

  • Pods que especificam um valor não raiz válido para o PodSecurityContext runAsUser não são afetados e continuam funcionando como esperado.
  • PodSecurityPolicies que aplicam uma configuração runAsUser tampouco são afetadas e continuam funcionando como esperado.
  • Pods que especificam mustRunAsNonRoot:true não iniciarão como UID 0, mas ocorrerá um erro ao iniciarem quando impactados por esse problema.
O que devo fazer?

Configure o Contexto de segurança RunAsUser (em inglês) em todos os pods no cluster que não devem ser executados como UID 0. É possível aplicar essa configuração usando uma PodSecurityPolicy.

Médio CVE-2019-11245

14 de maio de 2019

Descrição Gravidade Observações

Atualização de 11/06/2019: o patch está disponível nas versões 1.11.10-gke.4, 1.12.8-gke.6 e 1.13.6-gke.5 lançadas na semana de 28/05/2019 e outras posteriores.

A Intel divulgou as CVEs a seguir:

Elas são coletivamente denominadas "amostragem de dados de microarquitetura" (MDS). Essas vulnerabilidades possibilitam a exposição de dados por meio da interação da execução especulativa com o estado de microarquitetura. Para ver mais detalhes, consulte a divulgação da Intel.

A infraestrutura do host na qual o Kubernetes Engine é executado isola as cargas de trabalho do cliente umas das outras. A menos que você esteja executando um código não confiável dentro de seus clusters multilocatários do GKE, você não é impactado.

Para clientes que estão executando um código não confiável nos seus serviços multilocatários dentro do Kubernetes Engine, isso é uma vulnerabilidade particularmente severa. Para reduzi-la no Kubernetes Engine, desative o Hyper-Threading nos seus nós. Apenas os nós do Google Kubernetes Engine (GKE) que usam várias CPUs são afetados por essas vulnerabilidades. Observe que as VMs n1-standard-1 (padrão do GKE), g1-small e f1-micro expõem apenas uma vCPU para o ambiente convidado. Por isso, não é necessário desativar o Hyper-Threading.

Proteções adicionais para ativar a funcionalidade de despejo serão incluídas em uma futura versão de patch. Faremos upgrade automático dos mestres e dos nós para a versão com patch nas próximas semanas, no ritmo normal de upgrades. Apenas o patch não é suficiente para mitigar a exposição a essa vulnerabilidade. Veja as ações recomendadas abaixo.

Se o GKE On-Prem for executado, você poderá ser afetado dependendo do hardware utilizado. Consulte o anúncio da Intel.

O que fazer?

Você não é impactado, a menos que esteja executando um código não confiável dentro dos seus clusters multilocatários do GKE.

Para nós no Kubernetes Engine, crie novos nós com o Hyper-Threading desativado e reprograme as cargas de trabalho em novos nós.

Observe que as VMs n1-standard-1, g1-small e f1-micro expõem apenas uma vCPU para o ambiente convidado. Por isso, não é necessário desativar o Hyper-Threading.

Aviso:
  • Desativar o Hyper-Threading pode ter um impacto severo nos clusters e no aplicativo. Verifique se isso é permitido antes de implantar nos seus clusters de produção.
  • É possível desativar o Hyper-threading no nível do pool de nós do GKE com a implantação de um DaemonSet. Contudo, implantar esse DaemonSet reinicializará todos os seus nós no pool de nós ao mesmo tempo. Portanto, é recomendável criar um novo pool de nós no cluster, implantar o DaemonSet para desativar o Hyper-Threading naquele pool de nós e, então, migrar as cargas de trabalho para o novo pool de nós.

Para criar um novo pool de nós com o Hyper-Threading desativado:

  1. Crie um novo pool de nós no cluster com o rótulo de nó cloud.google.com/gke-smt-disabled=true: 
    
gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \
    --node-labels=cloud.google.com/gke-smt-disabled=true
  2. Implante o DaemonSet para esse novo pool de nós. O DaemonSet será executado somente em nós com o rótulo cloud.google.com/gke-smt-disabled=true. Ele desativará o Hyper-Threading e, depois, reinicializará o nó. 
    
kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
  3. Verifique se os pods do DaemonSet estão no estado de execução. 
    
kubectl get pods --selector=name=disable-smt -n kube-system

    Você receberá uma resposta semelhante a:

    
NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m
  4. Verifique se "SMT foi desativada" aparece nos registros dos pods. 
    
kubectl logs disable-smt-2xnnc disable-smt -n kube-system

É necessário manter o DaemonSet em execução nos pools de nós para que as alterações sejam aplicadas automaticamente aos novos nós criados no pool. É possível acionar as criações de nós por meio do reparo automático de nós, do upgrade manual ou automático e do escalonamento automático.

Para reativar o Hyper-Threading, é necessário recriar o pool de nós sem implantar o DaemonSet fornecido e migrar as cargas de trabalho para o novo pool de nós.

Também é recomendável fazer o upgrade manual dos nós assim que o patch estiver disponível. Para fazer o upgrade, primeiro é necessário fazer upgrade do mestre para a versão mais recente. O upgrade dos mestres do GKE será feito automaticamente no ritmo normal de upgrades.

Este boletim será atualizado com as versões com um patch assim que eles estiverem disponíveis.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz as vulnerabilidades a seguir:

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 e CVE-2019-11091 (páginas em inglês): essas vulnerabilidades exploram uma execução especulativa. Elas são coletivamente denominadas "amostragem de dados de microarquitetura" (MDS). Essas vulnerabilidades possibilitam a exposição de dados por meio da interação da execução especulativa com o estado de microarquitetura. 		Médio

5 de abril de 2019

Descrição Gravidade Observações

Recentemente, as vulnerabilidades de segurança CVE-2019-9900 e CVE-2019-9901. foram descobertas no Envoy (páginas em inglês).

O Envoy é incorporado ao Istio, e essas vulnerabilidades possibilitam que a política do Istio seja contornada em alguns casos.

Se você ativou o Istio no Google Kubernetes Engine (GKE), talvez seja impactado por essas vulnerabilidades. É recomendável fazer o upgrade dos clusters afetados para a versão de patch mais recente o quanto antes, e o upgrade dos arquivos secundários do Istio (instruções abaixo).

O que devo fazer?

Devido à gravidade dessas vulnerabilidades, tendo ou não ativado o upgrade automático de nós, é recomendável:

  1. Fazer upgrade manual do cluster assim que o patch estiver disponível.
  2. Fazer upgrade dos seus arquivos secundários seguindo a documentação de upgrade de arquivos secundários.

As versões em patch serão disponibilizadas para todos os projetos do GKE hoje, antes das 7:00 PM PDT.

Esse patch será disponibilizado nas versões do GKE abaixo. Os novos clusters usarão a versão com patch por padrão quando anunciada na página de boletins de segurança do GKE. A previsão é para 15 de abril de 2019. Se um novo cluster for criado antes disso, será necessário especificar a versão com patch que ele precisará usar. A atualização dos nós de clientes do GKE que ativaram os upgrades automáticos de nós e não fazem upgrade manual será feita automaticamente para as versões com patch na semana seguinte

Versões com patch:

  • 1.10.12-gke.14
  • 1.11.6-gke.16
  • 1.11.7-gke.18
  • 1.11.8-gke.6
  • 1.12.6-gke.10
  • 1.13.4-gke.10

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz as vulnerabilidades a seguir:

CVE-2019-9900 e CVE-2019-9901. Saiba mais sobre elas no blog da Istio.

Alta

1º de março de 2019

Descrição Gravidade Observações

Atualização de 22/03/2019: esse patch está disponível no Kubernetes versões 1.11.8-gke.4, 1.13.4-gke.1 e posteriores. O patch ainda não está disponível na versão 1.12. Acompanhe a disponibilidade desses patches nas notas de lançamento.

Recentemente, o Kubernetes descobriu uma vulnerabilidade de negação de serviço CVE-2019-1002100 (em inglês). Ela possibilita que um usuário autorizado faça solicitações de patch para criar uma solicitação "json-patch" mal-intencionada que consome quantidades excessivas de CPU e memória no servidor da API Kubernetes, potencialmente reduzindo a disponibilidade do plano de controle do cluster. Para ver mais detalhes, consulte a divulgação do Kubernetes. Todos os mestres do Google Kubernetes Engine (GKE) são afetados por essas vulnerabilidades. Uma futura versão de patch incluirá uma mitigação dessa vulnerabilidade. Faremos upgrade automático dos mestres do cluster para a versão com patch nas próximas semanas, no ritmo normal de upgrades.

O que devo fazer?

Nenhuma ação é necessária. O upgrade dos mestres do GKE será feito automaticamente, no ritmo normal de upgrades. Se quiser fazer isso antes, inicie o upgrade do mestre manualmente.

Este boletim será atualizado com as versões com um patch assim que estiverem disponíveis. Observe que o patch estará disponível apenas nas versões 1.11+, não nas 1.10.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2019-1002100 (em inglês) permite que um usuário crie especialmente um patch do tipo "json-patch" que consome quantidades excessivas de CPU no servidor da API Kubernetes, potencialmente reduzindo a disponibilidade do plano de controle do cluster.

Médio CVE-2019-1002100

11 de fevereiro de 2019 (RunC)

Descrição Gravidade Observações

Recentemente, a Open Containers Initiative (iniciativa que cria padrões para contêineres) descobriu uma nova vulnerabilidade de segurança no RunC, a CVE-2019-5736, que possibilita que um contêiner insira caracteres de escape para conseguir privilégios raiz no nó do host.

Seus nós de Ubuntu do Kubernetes Engine (GKE) são afetados por essas vulnerabilidades. Recomendamos que você faça upgrade para a versão de patch mais recente assim que possível, conforme detalhado abaixo.

O que devo fazer?

Para fazer upgrade dos seus nós, primeiro você precisa atualizar sua instância mestre para a versão mais recente. Esse patch está disponível para Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 e para as versões mais recentes. Acompanhe a disponibilidade desses patches nas notas de lançamento.

Apenas os nós do Ubuntu no GKE são afetados. Nós que executam COS não são afetados.

A nova versão do RunC tem uso maior de memória e pode exigir a atualização da memória alocada para contêineres se você tiver limites baixos (< 16MB) configurados.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

CVE-2019-5736 descreve uma vulnerabilidade no RunC que permite que um contêiner mal-intencionado (com interação mínima do usuário na forma de exec) substitua o binário RunC do host e, assim, consiga execução de código no nível raiz no nó host. Contêineres não executados como raiz não são afetados. Isso é classificado como uma vulnerabilidade de alto nível de gravidade.

 Alta CVE-2019-5736

11 de fevereiro de 2019 (Go)

Descrição Gravidade Observações

Atualização de 25/02/2019: o patch não está disponível na versão 1.11.7-gke.4, conforme comunicado anteriormente. Se você usa a versão 1.11.7, é possível fazer downgrade para a 1.11.6, upgrade para a 1.12 ou aguardar pelo patch da 1.11.7, disponível a partir da semana de 04/03/2019.

A linguagem de programação Go recentemente descobriu uma nova vulnerabilidade de segurança, CVE-2019-6486, que é uma negação de serviço (DoS) nas implementações de criptografia/elípticas das curvas elípticas P-521 e P-384. No Google Kubernetes Engine (GKE), isso permitiria um usuário a criar solicitações mal-intencionadas que consomem uma quantidade excessiva de CPU no servidor da API Kubernetes, potencialmente reduzindo a disponibilidade do plano de controle do cluster. Para mais detalhes, consulte a divulgação da Linguagem de programação Go.

Todos os mestres do Google Kubernetes Engine (GKE) são afetados por essas vulnerabilidades. A versão de patch mais recente inclui uma mitigação dessa vulnerabilidade. Faremos upgrade automático dos clusters mestres para a versão com patch nas próximas semanas, no ritmo normal de atualização.

O que fazer?

Nenhuma ação é necessária. O upgrade dos mestres do GKE será feito automaticamente no ritmo normal de upgrades. Se quiser fazer isso antes, inicie o upgrade do mestre manualmente.

Esse patch está disponível no 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 e nas versões mais recentes.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

CVE-2019-6486 é uma vulnerabilidade nas implementações de criptografia/elípticas das curvas elípticas P-521 e P-384. Isso permite que um usuário crie entradas que consomem uma quantidade excessiva de CPU.

Alto CVE-2019-6486

3 de dezembro de 2018

Descrição Gravidade Observações

Recentemente foi descoberta no Kubernetes uma nova vulnerabilidade de segurança CVE-2018-1002105 que permite a usuários com níveis de privilégio relativamente baixo ignorar a autorização de acesso às APIs do kubelet. Com isso, eles podem executar operações arbitrárias em qualquer pod e em qualquer nó do cluster. Para ver mais detalhes, consulte a divulgação do Kubernetes. Todas as instâncias mestras do Google Kubernetes Engine (GKE) foram afetadas por essas vulnerabilidades. O upgrade dos clusters para as versões de patch mais recentes já foi feito. Nenhuma ação é necessária.

O que devo fazer?

Nenhuma ação é necessária. O upgrade das instâncias mestras do GKE já foi feito.

Esse patch está disponível no GKE 1.9.7-gke.11, 1.10.6-gke.11, 1.10.7-gke.11, 1.10.9-gke.5, 1.11.2-gke.18 e nas versões mais recentes.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2018-1002105 possibilita que um usuário com privilégios relativamente baixos contorne a autorização para as APIs do kubelet. Com isso, um usuário com autorização para fazer solicitações de upgrade pode encaminhar e fazer chamadas arbitrárias à API do kubelet. Essa é uma vulnerabilidade crítica no Kubernetes. Com base em alguns detalhes na implementação do GKE que impediram o caminho de intensificação não autorizado, podemos classificar a vulnerabilidade como alta.

Alto CVE-2018-1002105

13 de novembro de 2018

Descrição

Atualização de 16/11/2018: a revogação e a rotação de todos os tokens potencialmente afetados foram concluídas. Você não precisa fazer mais nada.

O Google descobriu recentemente um problema no plug-in da interface de rede de contêiner (CNI, na sigla em inglês) do Project Calico. Em determinadas configurações, isso pode causar o registro de informações confidenciais. O problema está sendo monitorado pela deliberação técnica da Tigera TTA-2018-001 (em inglês).

  • Se executado com geração de registros no nível de depuração, o plug-in da CNI do Calico gravará a configuração do cliente da API Kubernetes nos registros.
  • A CNI do Calico também gravará o token da API Kubernetes no nível de informação dos registros se o campo “k8s_auth_token” estiver definido na configuração de rede da CNI.
  • Além disso, no caso de execução do plug-in com geração de registros no nível de depuração, se o token da conta de serviço estiver definido de modo explícito no arquivo de configuração lido pelo Calico ou como uma variável de ambiente usada pelo Calico, os respectivos componentes (calico/node, felix, CNI) gravarão essas informações nos arquivos de registro.

Esses tokens têm as seguintes permissões: 


bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]

Os clusters do Google Kubernetes Engine que têm uma política de rede de cluster e o Stackdriver Logging ativados registraram os tokens da conta de serviço do Calico no Stackdriver. Clusters sem a ativação da política de rede não foram afetados.

Implantamos uma correção que migra o plug-in da CNI do Calico para gravar apenas no nível de aviso e usar uma nova conta de serviço. O código com patch será implantado em uma versão posterior.

Ao longo da próxima semana, executaremos uma revogação gradual de todos os potenciais tokens afetados. Este boletim será atualizado quando a revogação for concluída. Não é necessária nenhuma ação da sua parte. Essa rotação foi concluída em 16/11/2018.

Se você quiser rotacionar esses tokens imediatamente, execute o comando a seguir. A nova chave secreta da conta de serviço deverá ser recriada automaticamente em alguns segundos: 


kubectl get sa --namespace kube-system calico -o template --template '{{(index .secrets 0).name}}' | xargs kubectl delete secret --namespace kube-system

Detecção

O GKE registra todos os acessos ao servidor da API. Para determinar se um token do Calico foi usado fora do intervalo de IPs esperado, execute a consulta do Stackdriver a seguir. Observação: a consulta retornará apenas registros de chamadas feitas fora da rede do GCP. Faça as alterações necessárias de acordo com seu ambiente específico. 


resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")

14 de agosto de 2018

Descrição Gravidade Observações

A Intel divulgou as seguintes Vulnerabilidades e Exposições Comuns (CVEs, na sigla em inglês):

Essas CVEs são coletivamente denominadas "L1 Terminal Fault (L1TF)".

As vulnerabilidades desse tipo atacam a configuração de estruturas de dados no nível do processador para explorar a execução especulativa. "L1" se refere ao cache de dados de nível 1 (L1D), um pequeno recurso dos núcleos usado para acelerar o acesso à memória.

Leia a postagem do blog do Google Cloud para ver mais detalhes sobre essas vulnerabilidades e os recursos do Compute Engine que ajudam a reduzir o impacto delas.

Impacto no Google Kubernetes Engine

A infraestrutura que executa o Kubernetes Engine e isola os clusters e os nós do cliente é protegida contra ameaças conhecidas.

Os pools de nós do Kubernetes Engine que usam a imagem do SO do Google otimizada para contêineres e estão com o upgrade automático ativado receberão as versões da imagem do SO para contêineres com o patch aplicado conforme elas forem disponibilizadas, a partir de 20 de agosto de 2018.

Os pools de nós do Kubernetes Engine que não estiverem com o upgrade automático ativado precisarão fazer o upgrade manualmente conforme as versões com patch da imagem do COS forem disponibilizadas.

Alto

6 de agosto de 2018. Última atualização: 5 de setembro de 2018

Descrição Gravidade Observações

Atualização: 9 de setembro de 2018

O boletim sobre a CVE-2018-5391 foi divulgado recentemente. Assim como a CVE-2018-5390, é uma vulnerabilidade de rede no nível do kernel que aumenta a eficiência de ataques de negação de serviço (DoS) contra sistemas vulneráveis. A principal diferença é que a CVE-2018-5391 pode ser explorada por meio de conexões IP. Atualizamos este boletim para detalhar as duas vulnerabilidades.

Descrição

Na CVE-2018-5390 ("SegmentSmack"), há a descrição de uma vulnerabilidade de rede no nível do kernel que aumenta a eficácia de ataques de negação de serviço (DoS) em sistemas vulneráveis com conexões TCP.

Na CVE-2018-5391 (“FragmentSmack”), você encontra a descrição de uma vulnerabilidade de rede no nível do kernel que aumenta a eficiência de ataques de negação de serviço (DoS) em sistemas vulneráveis por meio de conexões IP.

Impacto no Google Kubernetes Engine

Desde 11 de agosto de 2018, todas as instâncias mestre do Kubernetes Engine são protegidas contra essas duas vulnerabilidades. Além disso, todos os clusters desse serviço com a opção de upgrade automático ativada também estão protegidos. Os pools de nós que não estão com o upgrade automático ativado e foram atualizados manualmente pela última vez antes de 11 de agosto de 2018 podem ser afetados por essas duas vulnerabilidades.

Versões com patch aplicado

Devido à gravidade dessa vulnerabilidade, recomendamos que você faça o upgrade manual dos seus nós assim que o patch estiver disponível.

Alta

30 de maio de 2018

Descrição Gravidade Observações

Recentemente foi descoberta no Git uma vulnerabilidade que possibilita o escalonamento de privilégios no Kubernetes caso usuários sem privilégios tenham a permissão para criar pods com volumes gitRepo. A CVE é identificada pela tag CVE-2018-11235.

Meu ambiente foi afetado por essa vulnerabilidade?

Você pode ter sido afetado se todas as afirmações a seguir forem aplicáveis no seu caso:

  • Usuários que não são de confiança podem criar pods (ou acionar a criação deles).
  • Os pods criados por usuários que não são de confiança têm restrições que impedem o acesso root do host (por exemplo, por meio da PodSecurityPolicy).
  • Os pods criados por usuários que não são de confiança podem usar o tipo de volume "gitRepo".

Todos os nós do Kubernetes Engine estão vulneráveis.

O que devo fazer?

Proíba o uso do tipo de volume "gitRepo". Para proibir volumes de gitRepo com a PodSecurityPolicy, omita gitRepo da lista de permissões volumes na sua PodSecurityPolicy.

Clone um repositório git em um volume "EmptyDir" a partir de um "initContainer" para conseguir um comportamento equivalente ao do volume "gitRepo". 


apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

Qual patch corrige essa vulnerabilidade?

Um patch será incluído em uma das próximas versões do Kubernetes Engine. Volte a esta página em breve para mais detalhes.

Médio

21 de maio de 2018

Descrição Gravidade Observações

Diversas vulnerabilidades foram descobertas recentemente no kernel do Linux. Elas podem possibilitar o escalonamento de privilégios de negação de serviço (por meio da falha do kernel) a partir de um processo sem privilégios. Essas CVEs são identificadas pelas tags CVE-2018-1000199, CVE-2018-8897 e CVE-2018-1087. Todos os nós do Kubernetes Engine são afetados por essas vulnerabilidades. É recomendável fazer upgrade para a versão de patch mais recente, conforme detalhado a seguir.

O que fazer?

Para fazer o upgrade, primeiro você precisa atualizar sua instância mestra para a versão mais recente. Esse patch está disponível no Kubernetes Engine versões 1.8.12-gke.1, 1.9.7-gke.1 e 1.10.2-gke.1. Essas versões incluem patches para imagens do Ubuntu e do SO otimizadas para contêineres.

Se você criar um novo cluster antes disso, especifique qual é a versão com o patch para que ela seja usada. Os clientes que ativaram os upgrades de nós automáticos e não realizaram a atualização manualmente terão os nós atualizados para versões com patch nas próximas semanas.

Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz os riscos das seguintes vulnerabilidades:

CVE-2018-1000199: essa vulnerabilidade afeta o kernel do Linux. Ela permite que um usuário ou processo sem privilégios cause uma falha no kernel do sistema, o que levaria a um ataque de DoS ou um escalonamento de privilégios. Essa é uma vulnerabilidade de alta gravidade, com classificação de 7,8 no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS, na sigla em inglês).

CVE-2018-8897: essa vulnerabilidade afeta o kernel do Linux. Ela permite que um usuário ou processo sem privilégios cause uma falha no kernel do sistema, o que levaria a um ataque de DoS. Essa é uma vulnerabilidade de média gravidade, com classificação de 6,5 no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS, na sigla em inglês).

CVE-2018-1087: essa vulnerabilidade afeta o hipervisor KVM do kernel do Linux. Ela permite que um processo sem privilégios cause uma falha no kernel convidado ou possivelmente consiga privilégios. Um patch que corrige essa vulnerabilidade foi incluído na infraestrutura em que o Kubernetes Engine é executado, portanto, esse serviço não é afetado. Essa é uma vulnerabilidade de alta gravidade, com classificação de 8,0 no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS, na sigla em inglês).

Alta

12 de março de 2018

Descrição Gravidade Observações

O projeto Kubernetes divulgou recentemente novas vulnerabilidades de segurança, a CVE-2017-1002101 e a CVE-2017-1002102. Elas possibilitam que os contêineres acessem arquivos que não estão dentro deles. Todos os nós do Kubernetes Engine são afetados por essas vulnerabilidades. Recomendamos que você faça o upgrade para a versão com patch mais recente assim que possível.

O que devo fazer?

Devido à gravidade dessas vulnerabilidades, mesmo que você tenha ativado os upgrades automáticos, recomendamos que faça o upgrade manual dos seus nós assim que o patch estiver disponível. Isso deve acontecer até 16 de março, mas, de acordo com a programação de lançamento, talvez você tenha acesso a ele antes com base na zona do seu cluster.

Para fazer o upgrade, primeiro você precisa atualizar sua instância mestra para a versão mais recente. Esse patch está disponível no Kubernetes versões 1.9.4-gke.1, 1.8.9-gke.1 e 1.7.14-gke.1. Os novos clusters usarão a versão com patch por padrão até 30 de março. Se você criar um novo cluster antes disso, especifique qual é a versão com o patch para que ela seja usada.

Os clientes que ativaram os upgrades de nós automáticos e não realizaram a atualização manualmente terão os nós atualizados para versões com patch até 23 de abril. No entanto, devido à natureza dessa vulnerabilidade, é recomendável fazer o upgrade manual dos seus nós assim que o patch estiver disponível.

Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz os riscos das seguintes vulnerabilidades:

Com a vulnerabilidade CVE-2017-1002101, os contêineres que usam ativações do volume subpath podem acessar arquivos fora do volume. Com isso, se você tiver bloqueado o acesso do contêiner aos volumes do caminho do host com a PodSecurityPolicy, um intruso com capacidade de atualizar ou criar pods poderá ativar qualquer caminho de host usando outro tipo de volume.

A vulnerabilidade CVE-2017-1002102 possibilita que contêineres que usam certos tipos de volume, incluindo chaves secretas, mapas de configuração, volumes projetados ou APIs decrescentes, excluam arquivos que estão fora do volume. Isso significa que, se um contêiner que usa um desses tipos de volume for comprometido ou você permitir que usuários que não são de confiança criem pods, um intruso poderá usar esse contêiner para excluir arquivos aleatórios no host.

Para saber mais sobre a correção, leia a postagem do blog do Kubernetes.

Alto

Boletins de segurança do GKE no VMware

16 de outubro de 2019

Descrição Gravidade Observações

Uma vulnerabilidade foi descoberta no Kubernetes recentemente, descrita em CVE-2019-11253 (em inglês). Ela permite que qualquer usuário autorizado faça solicitações POST para executar 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, que podem ser encontradas aqui.

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

O que fazer?

É recomendável fazer upgrade dos clusters para uma versão de patch com a correção assim que ela estiver disponível.

As versões de patch que contêm a correção estão listadas abaixo:

  • GKE Enterprise 1.1.1, que executa o Kubernetes versão 1.13.7-gke.30
Qual vulnerabilidade é corrigida por esse patch?

O patch mitiga a seguinte vulnerabilidade: CVE-2019-11253.

Alta

CVE-2019-11253

23 de agosto de 2019

Descrição Gravidade Observações

Descobrimos e mitigamos uma vulnerabilidade em que o proxy RBAC, usado para proteger os endpoints de monitoramento, não autorizou corretamente os usuários. Consequentemente, as métricas de determinados componentes estão disponíveis para usuários não autorizados na rede interna do cluster. Os seguintes componentes foram afetados:

  • etcd
  • etcd-events
  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • node-exporter
  • kube-state-metrics
  • prometheus
  • alertmanager
O que devo fazer?

Recomendamos que você faça upgrade dos clusters para a versão 1.0.2-gke.3, que inclui o patch dessa vulnerabilidade, o mais rápido possível.

Médio

Lançamentos do GKE no VMware

22 de agosto de 2019

Descrição Gravidade Observações

Recentemente, o Kubernetes descobriu uma vulnerabilidade, a CVE-2019-11247, que possibilita que instâncias de recursos personalizados com escopo no cluster sejam usadas como se fossem objetos de namespaces existentes em todos os namespaces. Isso significa que contas de usuários e de serviço com permissões apenas do RBAC de nível do namespace podem interagir com recursos personalizados com escopo no cluster. A exploração dessa vulnerabilidade exige que o invasor tenha privilégios para acessar o recurso no namespace.

O que devo fazer?

Recomendamos que você faça upgrade dos clusters para a versão 1.0.2-gke.3, que inclui o patch dessa vulnerabilidade, o mais rápido possível.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz a seguinte vulnerabilidade: CVE-2019-11247.

Médio

CVE-2019-11247