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 para os 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

Publicado: 2019-11-14
Atualizado: 2019-11-14
Descrição Gravidade Notas

O Kubernetes divulgou um problema de segurança nos sidecars kubernetes-csi external-provisioner, external-snapshotter> e external-resizer que afeta a maioria das versões dos sidecars incluídos nos controladores da interface de armazenamento de contentores (CSI). Para mais detalhes, consulte a divulgação do Kubernetes.

O que devo fazer?
Esta vulnerabilidade não afeta nenhum componente do GKE gerido. Pode ser afetado se gerir os seus próprios controladores CSI em clusters alfa do GKE que executam a versão 1.12 ou superior do GKE. Se for afetado, contacte o fornecedor do controlador CSI para obter instruções de atualização.

Que vulnerabilidades são abordadas por esta correção?
CVE-2019-11255: Este CVE é uma vulnerabilidade nos sidecars kubernetes-csi external-provisioner, external-snapshotter, e external-resizer que podem permitir o acesso ou a mutação não autorizados de dados de volume. Isto afeta a maioria das versões dos sidecars incluídos nos controladores CSI.

Médio

CVE-2019-11255

12 de novembro de 2019

Publicado: 2019-11-12
Atualizado: 2019-11-12
Descrição Gravidade Notas

A Intel divulgou CVEs que permitem potencialmente interações entre a execução especulativa e o estado microarquitetónico para expor dados. Para mais detalhes, consulte a divulgação da Intel.

A infraestrutura de anfitrião que executa o Kubernetes Engine isola as cargas de trabalho dos clientes. A menos que esteja a executar código não fidedigno nos seus próprios clusters GKE multiinquilinos e a usar nós N2, M2 ou C2, não é necessária nenhuma ação adicional. Para instâncias do GKE em nós N1, não é necessária nenhuma nova ação.

Se estiver a executar o Google Distributed Cloud, a exposição depende do hardware. Compare a sua infraestrutura com a divulgação da Intel.

O que devo fazer?

Só é afetado se estiver a usar conjuntos de nós com nós N2, M2 ou C2 e esses nós executarem código não fidedigno nos seus próprios clusters GKE multiinquilinos.

O reinício dos nós aplica a correção. A forma mais simples de reiniciar todos os nós no conjunto de nós é usar a operação de atualização para forçar um reinício em todo o conjunto de nós afetado.

Que vulnerabilidades são abordadas por esta correção?

A correção mitiga as seguintes vulnerabilidades:

CVE-2019-11135: Este CVE também é conhecido como TSX Async Abort (TAA). A TAA oferece outra via para a exfiltração de dados através das mesmas estruturas de dados microarquitetónicas que foram exploradas pela amostragem de dados microarquitetónicos (MDS).

CVE-2018-12207 Esta é uma vulnerabilidade de negação de serviço (DoS) que afeta os anfitriões de máquinas virtuais, permitindo que um convidado malicioso provoque uma falha num anfitrião não protegido. Esta CVE também é conhecida como "Machine Check Error on Page Size Change". Isto não afeta o GKE.

Médio

CVE-2019-11135
CVE-2018-12207

22 de outubro de 2019

Publicado: 2019-10-22
Atualizado: 2019-10-22
Descrição Gravidade Notas

Foi descoberta recentemente uma vulnerabilidade na linguagem de programação Go, descrita em CVE-2019-16276. Esta vulnerabilidade afeta potencialmente as configurações do Kubernetes que usam um proxy de autenticação. Para mais detalhes, consulte a divulgação do Kubernetes.

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

Nenhum

CVE-2019-16276

16 de outubro de 2019

Publicado: 2019-10-16
Atualizado: 2019-10-24
Descrição Gravidade Notas

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

Foi recentemente descoberta uma vulnerabilidade no Kubernetes, descrita em CVE-2019-11253, que permite a qualquer utilizador autorizado a fazer pedidos POST executar um ataque de negação de serviço remoto num servidor da API Kubernetes. O Kubernetes Product Security Committee (PSC) divulgou informações adicionais sobre esta vulnerabilidade que podem ser encontradas aqui.

Os clusters do GKE que usam redes autorizadas principais e clusters privados sem ponto final público mitigam esta vulnerabilidade.

O que devo fazer?

Recomendamos que atualize o cluster para uma versão de patch que contenha a correção assim que estiverem disponíveis. Esperamos que estejam disponíveis em todas as zonas com o lançamento do GKE planeado para a semana de 14 de outubro.

As versões de patch que vão conter a mitigação estão listadas abaixo:

  • 1.12.10-gke.15
  • 1.13.11-gke.5
  • 1.14.7-gke.10
  • 1.15.4-gke.15
Que vulnerabilidades são abordadas por esta correção?

A correção mitiga as seguintes vulnerabilidades:

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

Alto

CVE-2019-11253

16 de setembro de 2019

Publicado: 2019-09-16
Atualizado: 2019-10-16
Descrição Gravidade Notas

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

A linguagem de programação Go descobriu recentemente novas vulnerabilidades de segurança CVE-2019-9512 e CVE-2019-9514, que são vulnerabilidades de negação de serviço (DoS). No GKE, isto pode permitir que um utilizador crie pedidos maliciosos que consomem quantidades excessivas de CPU no servidor da API Kubernetes, o que pode reduzir a disponibilidade do plano de controlo do cluster. Para mais detalhes, consulte a divulgação da linguagem de programação Go.

O que devo fazer?

Recomendamos que atualize o cluster para a versão de patch mais recente, que contém a mitigação desta vulnerabilidade, assim que estiver disponível. Esperamos que estejam disponíveis em todas as zonas com o próximo lançamento do GKE, de acordo com o cronograma de lançamentos.

As versões de patch que vão conter a mitigação estão listadas abaixo:

  • Atualização de 16 de outubro de 2019: 1.12.10-gke.15
  • 1.13.10-gke.0
  • 1.14.6-gke.1
Que vulnerabilidade é resolvida por esta correção?

A correção mitiga as seguintes vulnerabilidades:

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

Alto

CVE-2019-9512
CVE-2019-9514

5 de setembro de 2019

Publicado: 05/09/2019
Atualizado: 05/09/2019

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

22 de agosto de 2019

Publicado: 2019-08-22
Atualizado: 2019-08-22

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

Publicado: 2019-08-08
Atualizado: 2019-08-08

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

5 de agosto de 2019

Publicado: 2019-08-05
Atualizado: 2019-08-09
Descrição Gravidade Notas

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

O Kubernetes descobriu recentemente uma vulnerabilidade, CVE-2019-11247, que permite que as instâncias de recursos personalizados ao nível do cluster sejam tratadas como se fossem objetos com espaço de nomes existentes em todos os espaços de nomes. Isto significa que as contas de utilizador e de serviço com autorizações RBAC apenas ao nível do espaço de nomes podem interagir com recursos personalizados ao nível do cluster. A exploração desta vulnerabilidade requer que o atacante tenha privilégios para aceder ao recurso em qualquer espaço de nomes.

O que devo fazer?

Recomendamos que atualize o cluster para a versão de patch mais recente, que contém a mitigação desta vulnerabilidade, assim que estiverem disponíveis. Esperamos que estejam disponíveis em todas as zonas com o próximo lançamento do GKE. As versões de patch que contêm a mitigação estão listadas abaixo:

  • 1.11.10-gke.6
  • 1.12.9-gke.13
  • 1.13.7-gke.19
  • 1.14.3-gke.10 (canal rápido)
Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade: CVE-2019-11247.

Médio

CVE-2019-11247

3 de julho de 2019

Publicado: 2019-07-03
Atualizado: 2019-07-03
Descrição Gravidade Notas

Já está disponível uma versão corrigida do kubectl para resolver o CVE-2019-11246 com o gcloud 253.0.0. Consulte o boletim de segurança de 25 de junho de 2019 para mais informações.

Nota: a correção não está disponível na versão kubectl 1.11.10.

Alto

CVE-2019-11246

3 de julho de 2019

Publicado: 2019-06-25
Atualizado: 2019-07-03
Descrição Gravidade Notas
Atualização de 3 de julho de 2019

No momento da nossa última atualização, os patches para as versões 1.11.9 e 1.11.10 ainda não estavam disponíveis. Já lançámos a versão 1.11.10-gke.5 como destino de atualização para ambas as versões 1.11.

Neste momento, os mestres do GKE foram corrigidos e a infraestrutura da Google que executa o Kubernetes Engine foi corrigida e está protegida contra esta vulnerabilidade.

Os mestres 1.11 vão ser descontinuados em breve e a atualização para a versão 1.12 está agendada para a semana de 8 de julho de 2019. Pode escolher qualquer uma das seguintes ações sugeridas para obter nós numa versão corrigida:

  • Realize a atualização de nós para a versão 1.11.10-gke.5 até 8 de julho de 2019. Após esta data, as versões 1.11 vão começar a ser removidas da lista disponível de destinos de atualização.
  • Ative as atualizações automáticas em nós 1.11 e permita que sejam atualizados quando os mestres forem atualizados para 1.12.
  • Atualize manualmente os mestres e os nós para uma versão 1.12 corrigida.

Segue-se o boletim original de 24 de junho de 2019:

Atualização de 24 de junho de 2019

A partir de 22/06/2019 às 21:40 UTC, disponibilizámos as seguintes versões corrigidas do Kubernetes. Os nós principais entre as versões 1.11.0 e 1.13.6 do Kubernetes vão ser atualizados automaticamente para uma versão corrigida. Se não estiver a executar uma versão compatível com esta correção, atualize para uma versão principal compatível (indicada abaixo) antes de atualizar os seus nós.

Devido à gravidade destas vulnerabilidades, quer tenha ou não a atualização automática de nós ativada, recomendamos que atualizemanualmente os nós e os mestres para uma destas versões o mais rapidamente possível.

As versões com patch:

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

Segue-se o boletim original de 18 de junho de 2019:

Recentemente, a Netflix divulgou três vulnerabilidades de TCP nos kernels do Linux:

Estas CVEs são coletivamente denominadas NFLX-2019-001.

Os kernels Linux sem patches podem ser vulneráveis a um ataque de negação de serviço acionado remotamente. Os nós do Google Kubernetes Engine que enviam ou recebem tráfego de rede não fidedigno são afetados, e recomendamos que siga estes passos de mitigação abaixo para proteger as suas cargas de trabalho.

Mestres do Kubernetes

  • Os mestres do Kubernetes que usam Redes autorizadas para limitar o tráfego a redes fidedignas não são afetados.

  • Os nós principais dos clusters do GKE, que são geridos pela Google, vão ser corrigidos automaticamente nos próximos dias. Não é necessária nenhuma ação da parte do cliente.

Nós do Kubernetes

Os nós que limitam o tráfego a redes fidedignas não são afetados. Este seria um cluster com o seguinte:

  • Nós protegidos por firewall de redes não fidedignas ou sem IPs públicos (clusters privados)
  • Clusters sem serviços LoadBalancer públicos

A Google está a preparar uma mitigação permanente para estas vulnerabilidades que vai ser disponibilizada como uma nova versão do nó. Vamos atualizar este boletim e enviar um email a todos os clientes do GKE quando a correção permanente for disponibilizada.

Até que a correção permanente esteja disponível, criámos um DaemonSet do Kubernetes que implementa mitigações modificando a configuração do anfitrião iptables.

O que devo fazer?

Aplique o Kubernetes DaemonSet a todos os nós no seu cluster executando o seguinte comando. Isto adiciona uma regra iptables às regras iptables existentes no nó para mitigar a vulnerabilidade. Execute o comando uma vez por cluster por Google Cloud projeto. 

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

Assim que estiver disponível uma versão corrigida do nó e tiver atualizado todos os nós potencialmente afetados, pode remover o DaemonSet com o seguinte comando. Execute o comando uma vez por cluster por Google Cloud projeto. 

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

25 de junho de 2019

Descrição Gravidade Notas

Atualização de 03/07/2019: esta correção está disponível na versão gcloud 253.0.0, para as versões kubectl 1.12.9, 1.13.6, 1.14.2 e lançamentos mais recentes.

Nota: a correção não está disponível na versão 1.11.10.

O Kubernetes descobriu recentemente uma vulnerabilidade, CVE-2019-11246, que permite que um atacante com acesso a uma operação kubectl cp e execução de código dentro de um contentor modifique ficheiros no anfitrião. Esta exploração permite potencialmente que um atacante substitua ou crie um ficheiro no sistema de ficheiros do anfitrião. Para mais detalhes, consulte a divulgação do Kubernetes.

Todas as versões do Google Kubernetes Engine (GKE) são afetadas por esta vulnerabilidade e recomendamos que atualize para a versão de patch mais recente do gcloud quando estiver disponível.gcloud Uma versão de patch futura vai incluir uma mitigação para esta vulnerabilidade.

O que devo fazer?

Uma versão corrigida do kubectl vai estar disponível num próximo lançamento do gcloud. Também pode atualizar kubectl diretamente.

Acompanhe a disponibilidade desta correção nas gcloudnotas de lançamento.

Que vulnerabilidade é resolvida por esta correção?

A vulnerabilidade CVE-2019-11246 permite que um atacante com acesso a uma operação kubectl cp e à execução de código num contentor modifique ficheiros no anfitrião. Esta exploração permite potencialmente a um atacante substituir ou criar um ficheiro no sistema de ficheiros do anfitrião

Alto

CVE-2019-11246

18 de junho de 2019

Descrição Gravidade Notas

A Docker descobriu recentemente uma vulnerabilidade, CVE-2018-15664, que permite a um atacante que consiga executar código num contentor roubar uma operação docker cp iniciada externamente. Esta exploração permite potencialmente a um atacante alterar a localização onde um ficheiro está a ser escrito para uma localização arbitrária no sistema de ficheiros do anfitrião.

Todos os nós do Google Kubernetes Engine (GKE) que executam o Docker são afetados por esta vulnerabilidade e recomendamos que atualize para a versão de patch mais recente assim que estiver disponível. Uma versão de patch futura vai incluir uma mitigação para esta vulnerabilidade.

Todos os mestres do Google Kubernetes Engine (GKE) com uma versão anterior a 1.12.7 estão a executar o Docker e são afetados por esta vulnerabilidade. No GKE, os utilizadores não têm acesso a docker cp no master e, por isso, o risco desta vulnerabilidade é limitado para os masters do GKE.

O que devo fazer?

Apenas os nós que executam o Docker são afetados e apenas quando é emitido um comando docker cp (ou equivalente da API) que pode ser roubado. Isto é considerado bastante invulgar num ambiente do Kubernetes. Os nós que executam o COS com o containerd não são afetados.

Para atualizar os seus nós, tem de atualizar primeiro o mestre para a versão corrigida. Quando o patch estiver disponível, pode iniciar uma atualização principal ou aguardar que a Google atualize automaticamente o nó principal. A correção vai estar disponível no Docker 18.09.7, incluído numa próxima correção do GKE. Esta correção só vai estar disponível para as versões 1.13 e superiores do GKE.

Vamos atualizar automaticamente os mestres do cluster para a versão corrigida, na cadência de atualização normal. Também pode iniciar uma atualização principal assim que a versão corrigida estiver disponível.

Vamos atualizar este boletim com as versões que contêm um patch assim que estiverem disponíveis. Acompanhe a disponibilidade destas correções nas notas de lançamento.

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade:

A vulnerabilidade CVE-2018-15664 permite que um atacante que possa executar código dentro de um contentor roube uma operação docker cp iniciada externamente. Esta exploração permite potencialmente a um atacante alterar a localização onde um ficheiro está a ser escrito para uma localização arbitrária no sistema de ficheiros do anfitrião.

Alto

31 de maio de 2019

Descrição Gravidade Notas

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

Atualização de 2 de agosto de 2019

No momento do boletim inicial, apenas as versões 1.13.6-gke.0 a 1.13.6-gke.5 foram afetadas. Devido a uma regressão, todas as versões 1.13.6.x são agora afetadas. Se estiver a usar a versão 1.13.6, atualize para a versão 1.13.7 assim que possível.

O projeto Kubernetes divulgou CVE-2019-11245 no kubelet v1.13.6 e v1.14.2, o que pode fazer com que os contentores sejam executados como UID 0 (normalmente, mapeia para o utilizador root), mesmo que seja especificado um utilizador diferente na imagem do contentor. Se os seus contentores forem executados como um utilizador não root e estiver a executar a versão do nó 1.13.6-gke.0 a 1.13.6-gke.6, recomendamos que defina RunAsUser em todos os pods no cluster cujos contentores não devem ser executados como UID 0.

Se for especificado um valor USER não raiz (por exemplo, definindo o valor de USER num Dockerfile), ocorre um comportamento inesperado. Quando um contentor é executado pela primeira vez num nó, respeita corretamente o UID especificado. No entanto, devido a esta falha, na segunda execução (e execuções subsequentes), o contentor é executado como UID 0, independentemente do UID especificado. Normalmente, trata-se de um privilégio aumentado indesejado e pode levar a um comportamento inesperado da aplicação.

Como posso saber se estou a usar uma versão afetada?

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

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

Se o resultado apresentar as versões do kubelet indicadas abaixo, os seus nós são afetados:

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

Se os seus contentores forem executados como um utilizador não root e estiver a executar a versão 1.13.6-gke.0 a 1.13.6-gke.6 do nó, é afetado, exceto nos seguintes casos:

  • Os pods que especificam um valor não raiz válido para o runAsUser PodSecurityContext não são afetados e continuam a funcionar como esperado.
  • As PodSecurityPolicies que aplicam uma definição de runAsUser também não são afetadas e continuam a funcionar como esperado.
  • Os pods que especificam mustRunAsNonRoot:true não são iniciados como UID 0, mas falham ao iniciar quando são afetados por este problema.
O que devo fazer?

Defina o contexto de segurança RunAsUser em todos os pods no cluster que não devem ser executados como UID 0. Pode aplicar esta configuração através de uma PodSecurityPolicy.

Médio CVE-2019-11245

14 de maio de 2019

Descrição Gravidade Notas

Atualização de 11/06/2019: a correção 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 em lançamentos mais recentes.

A Intel divulgou as seguintes CVEs:

Estas CVEs são coletivamente denominadas amostragem de dados microarquitetónicos (MDS). Estas vulnerabilidades permitem potencialmente que os dados sejam expostos através da interação da execução especulativa com o estado microarquitetónico. Para mais detalhes, consulte a divulgação da Intel.

A infraestrutura de anfitrião que executa o Kubernetes Engine isola as cargas de trabalho dos clientes entre si. A menos que esteja a executar código não fidedigno nos seus próprios clusters do GKE multiinquilino, não é afetado.

Para os clientes que executam código não fidedigno nos respetivos serviços multiinquilinos no Kubernetes Engine, esta é uma vulnerabilidade particularmente grave. Para a mitigar no Kubernetes Engine, desative a funcionalidade Hyper-Threading nos seus nós. Apenas os nós do Google Kubernetes Engine (GKE) que usam várias CPUs são afetados por estas vulnerabilidades. Tenha em atenção que as VMs n1-standard-1 (a predefinição do GKE), g1-small e f1-micro apenas expõem 1 vCPU ao ambiente convidado, pelo que não é necessário desativar o Hyper-Threading.

Serão incluídas proteções adicionais para ativar a funcionalidade de limpeza numa versão de patch futura. Vamos atualizar automaticamente os mestres e os nós com a atualização automática para a versão corrigida nas próximas semanas, à cadência de atualização normal. A correção por si só não é suficiente para mitigar a exposição a esta vulnerabilidade. Consulte abaixo as ações recomendadas.

Se estiver a executar o GKE on-prem, pode ser afetado consoante o hardware que estiver a usar. Consulte a divulgação da Intel.

O que devo fazer?

A menos que esteja a executar código não fidedigno nos seus próprios clusters do GKE multiinquilino, não é afetado.

Para nós no Kubernetes Engine, crie novos node pools com o Hyper-Threading desativado e reagende as suas cargas de trabalho para os novos nós.

Tenha em atenção que as VMs n1-standard-1, g1-small e f1-micro apenas expõem 1 vCPU ao ambiente convidado, pelo que não é necessário desativar o Hyper-Threading.

Aviso:
  • A desativação do Hyper-Threading pode ter um impacto significativo no desempenho dos seus clusters e aplicação. Certifique-se de que esta situação é aceitável antes de implementar esta funcionalidade nos seus clusters de produção.
  • A multithreading simultânea pode ser desativada ao nível do conjunto de nós do GKE através da implementação de um DaemonSet. No entanto, a implementação deste DaemonSet resulta no reinício de todos os nós no conjunto de nós ao mesmo tempo. Por conseguinte, é recomendável criar um novo conjunto de nós no seu cluster, implementar o DaemonSet para desativar o Hyper-Threading nesse conjunto de nós e, em seguida, migrar as suas cargas de trabalho para o novo conjunto de nós.

Para criar um novo node pool com a funcionalidade Hyper-Threading desativada:

  1. Crie um novo node pool no cluster com a etiqueta 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. Implemente o DaemonSet neste novo conjunto de nós. O DaemonSet só é executado em nós com a etiqueta cloud.google.com/gke-smt-disabled=true. Esta ação desativa a funcionalidade Hyper-Threading e, em seguida, reinicia o nó. 
    kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
  3. Certifique-se de que os pods DaemonSet estão em estado de execução. 
    kubectl get pods --selector=name=disable-smt -n kube-system

    Deve receber uma resposta semelhante à seguinte:

    NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m
  4. Verifique se a mensagem "SMT has been disabled" (O SMT foi desativado) aparece nos registos dos pods. 
    kubectl logs disable-smt-2xnnc disable-smt -n kube-system

Tem de manter o DaemonSet em execução nos nodepools para que os novos nós criados no pool tenham as alterações aplicadas automaticamente. As criações de nós podem ser acionadas pela autorreparação de nós, pela atualização manual ou automática e pelo dimensionamento automático.

Para reativar a funcionalidade Hyper-Threading, tem de recriar o node pool sem implementar o DaemonSet fornecido e migrar as suas cargas de trabalho para o novo node pool.

Também recomendamos que atualize manualmente os seus nós assim que o patch ficar disponível. Para fazer a atualização, primeiro tem de atualizar o seu dispositivo principal para a versão mais recente. Os mestres do GKE são atualizados automaticamente na cadência de atualização normal.

Vamos atualizar este boletim com as versões que contêm um patch assim que estiverem disponíveis.

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga as seguintes vulnerabilidades:

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091: Estas vulnerabilidades exploram a execução especulativa. Estas CVEs são denominadas coletivamente amostragem de dados microarquitetónica. Estas vulnerabilidades permitem potencialmente que os dados sejam expostos através da interação da execução especulativa com o estado microarquitetónico. 		Médio

5 de abril de 2019

Descrição Gravidade Notas

Recentemente, foram encontradas as vulnerabilidades de segurança CVE-2019-9900 e CVE-2019-9901. foram descobertas no Envoy.

Istio incorpora o Envoy, e estas vulnerabilidades permitem que a política do Istio seja ignorada em alguns casos.

Se tiver ativado o Istio no Google Kubernetes Engine (GKE), pode ser afetado por estas vulnerabilidades. Recomendamos que atualize os clusters afetados para a versão de patch mais recente assim que possível e que atualize os sidecars do Istio (instruções abaixo).

O que devo fazer?

Devido à gravidade destas vulnerabilidades, quer tenha ou não as atualizações automáticas de nós ativadas, recomendamos que:

  1. Atualize manualmente o cluster assim que o patch ficar disponível.
  2. Atualize os ficheiros SIDE CAR seguindo a documentação de atualização de ficheiros SIDE CAR.

As versões corrigidas vão ser disponibilizadas para todos os projetos do GKE antes das 19:00 PDT de hoje.

Este patch vai estar disponível nas versões do GKE abaixo. Os novos clusters vão usar a versão corrigida por predefinição quando for anunciada na página de boletins de segurança do GKE, prevista para 15 de abril de 2019. Se criar um novo cluster antes dessa data, tem de especificar a versão corrigida para que seja usada. Os clientes do GKE que tiverem as atualizações automáticas de nós ativadas e que não fizerem a atualização manual, vão ter os respetivos nós atualizados automaticamente para versões corrigidas na semana seguinte.

Versões com patches:

  • 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

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga as seguintes vulnerabilidades:

CVE-2019-9900 e CVE-2019-9901. Pode ler mais sobre estes recursos no blogue do Istio.

Alto

1 de março de 2019

Descrição Gravidade Notas

Atualização de 22/03/2019: esta correção está disponível no Kubernetes 1.11.8-gke.4, 1.13.4-gke.1 e versões mais recentes. A correção ainda não está disponível na versão 1.12. Acompanhe a disponibilidade destas correções nas notas de lançamento.

Recentemente, o Kubernetes descobriu uma nova vulnerabilidade de negação de serviço CVE-2019-1002100, que permite a um utilizador autorizado a fazer pedidos de patches criar um pedido "json-patch" malicioso que consome quantidades excessivas de CPU e memória no servidor da API Kubernetes, o que pode reduzir a disponibilidade do plano de controlo do cluster. Para mais detalhes, consulte a divulgação do Kubernetes. Todos os mestres do Google Kubernetes Engine (GKE) são afetados por estas vulnerabilidades. Uma versão de patch futura vai incluir uma mitigação para esta vulnerabilidade. Vamos atualizar automaticamente os mestres do cluster para a versão com patch nas próximas semanas, na cadência de atualização normal.

O que devo fazer?

Não é necessária qualquer ação da sua parte. Os mestres do GKE são atualizados automaticamente na cadência de atualização normal. Se quiser atualizar o mestre mais cedo, pode iniciar manualmente uma atualização do mestre.

Vamos atualizar este boletim com as versões que contêm um patch. Tenha em atenção que a correção só vai estar disponível nas versões 1.11 e posteriores, e não na versão 1.10.

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade:

A vulnerabilidade CVE-2019-1002100 permite que um utilizador crie especialmente uma correção do tipo "json-patch" que consome quantidades excessivas de CPU no servidor da API Kubernetes, reduzindo potencialmente a disponibilidade do plano de controlo do cluster.

Médio CVE-2019-1002100

11 de fevereiro de 2019 (runc)

Descrição Gravidade Notas

A Open Containers Initiative (OCI) descobriu recentemente uma nova vulnerabilidade de segurança CVE-2019-5736 no runc, que permite a fuga de contentores para obter privilégios de raiz no nó anfitrião.

Os seus nós do Ubuntu do Google Kubernetes Engine (GKE) são afetados por estas vulnerabilidades e recomendamos que atualize para a versão de patch mais recente assim que possível, conforme detalhamos abaixo.

O que devo fazer?

Para atualizar os seus nós, tem de atualizar primeiro o mestre para a versão mais recente. Esta correção está disponível no Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 e versões mais recentes. Acompanhe a disponibilidade destas correções nas notas de lançamento.

Tenha em atenção que apenas os nós do Ubuntu no GKE são afetados. Os nós que executam o COS não são afetados.

Tenha em atenção que a nova versão do runc aumentou a utilização de memória e pode exigir a atualização da memória alocada aos contentores se tiver definido limites de memória baixos (< 16 MB).

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade:

CVE-2019-5736 descreve uma vulnerabilidade no runc que permite que um contentor malicioso (com uma interação mínima do utilizador sob a forma de um exec) substitua o binário runc do anfitrião e, assim, obtenha a execução de código ao nível da raiz no nó do anfitrião. Os contentores que não são executados como raiz não são afetados. Esta é classificada como uma vulnerabilidade de gravidade "Alta".

 Alto CVE-2019-5736

11 de fevereiro de 2019 (Go)

Descrição Gravidade Notas

Atualização de 25/02/2019: a correção não está disponível na versão 1.11.7-gke.4, conforme comunicado anteriormente. Se estiver a usar a versão 1.11.7, pode: fazer o downgrade para a versão 1.11.6, fazer o upgrade para a versão 1.12 ou aguardar até que o patch 1.11.7 seguinte esteja disponível na semana de 04/03/2019.

A linguagem de programação Go descobriu recentemente uma nova vulnerabilidade de segurança CVE-2019-6486, que é uma vulnerabilidade de negação de serviço (DoS) nas implementações crypto/elliptic das curvas elípticas P-521 e P-384. No Google Kubernetes Engine (GKE), isto pode permitir que um utilizador crie pedidos maliciosos que consumam quantidades excessivas de CPU no servidor da API Kubernetes, o que pode reduzir a disponibilidade do plano de controlo 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 estas vulnerabilidades. A versão de patch mais recente Inclui uma mitigação para esta vulnerabilidade. Vamos atualizar os mestres do cluster para a versão corrigida automaticamente nas próximas semanas, na cadência de atualização normal.

O que devo fazer?

Não é necessária qualquer ação da sua parte. Os mestres do GKE são atualizados automaticamente na cadência de atualização normal. Se quiser atualizar o mestre mais cedo, pode iniciar manualmente uma atualização do mestre.

Esta correção está disponível no GKE 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 e versões mais recentes.

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade:

O CVE-2019-6486 é uma vulnerabilidade nas implementações crypto/elliptic das curvas elípticas P-521 e P-384. Isto permite que um utilizador crie entradas que consomem quantidades excessivas de CPU.

Alto CVE-2019-6486

3 de dezembro de 2018

Descrição Gravidade Notas

O Kubernetes descobriu recentemente uma nova vulnerabilidade de segurança CVE-2018-1002105, que permite a um utilizador com privilégios relativamente baixos ignorar a autorização para as APIs do kubelet, dando a capacidade de executar operações arbitrárias para qualquer Pod em qualquer nó no cluster. Para mais detalhes, consulte a divulgação do Kubernetes. Todos os mestres do Google Kubernetes Engine (GKE) foram afetados por estas vulnerabilidades e já atualizámos os clusters para as versões de patch mais recentes. Não é necessária nenhuma ação.

O que devo fazer?

Não é necessária qualquer ação da sua parte. Os mestres do GKE já foram atualizados.

Esta correção 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 e 1.11.2-gke.18 e versões mais recentes.

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade:

A vulnerabilidade CVE-2018-1002105 permite que um utilizador com privilégios relativamente baixos contorne a autorização para as APIs do kubelet. Isto dá a um utilizador autorizado a fazer pedidos atualizáveis para aumentar e fazer chamadas arbitrárias para a API do kubelet. Esta é classificada como uma vulnerabilidade crítica no Kubernetes. Tendo em conta alguns detalhes na implementação do GKE que impediram o caminho de escalonamento não autenticado, esta situação é classificada como uma vulnerabilidade elevada.

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 estão concluídas. Não é necessária nenhuma ação adicional.

A Google descobriu recentemente um problema no plug-in da interface de rede de contentores (CNI) da Calico que, em determinadas configurações, pode registar informações confidenciais. Este problema é monitorizado ao abrigo do aviso técnico da Tigera TTA-2018-001.

  • Quando executado com o registo ao nível de depuração, o plug-in CNI do Calico escreve a configuração do cliente da API Kubernetes nos registos.
  • O CNI do Calico também escreve o token da API Kubernetes nos registos ao nível de informações se o campo "k8s_auth_token" estiver definido na configuração de rede do CNI.
  • Além disso, quando executado com o registo ao nível de depuração, se o token da conta de serviço for definido explicitamente, quer no ficheiro de configuração do Calico lido pelo Calico, quer como variáveis de ambiente usadas pelo Calico, os componentes do Calico (calico/node, felix, CNI) escrevem estas informações nos ficheiros de registo.

Estes tokens têm as seguintes autorizaçõ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 com uma política de rede de cluster e o Stackdriver Logging ativado registavam tokens de contas de serviço do Calico no Stackdriver. Os clusters sem a Política de rede ativada não são afetados.

Implementámos uma correção que migra o plugin CNI do Calico para registar apenas ao nível de aviso e usar uma nova conta de serviço. O código calico com patch vai ser implementado numa versão posterior.

Ao longo da próxima semana, vamos efetuar uma revogação progressiva de todos os tokens potencialmente afetados. Este boletim vai ser atualizado quando a revogação estiver concluída. Não tem de fazer mais nada. (Esta rotação foi concluída a 16/11/2018)

Se quiser rodar estes tokens imediatamente, pode executar o seguinte comando. O novo segredo da conta de serviço deve ser recriado 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

Deteção

O GKE regista todo o acesso ao servidor da API. Para determinar se foi usado um token do Calico fora do intervalo de IP esperado do Google Cloud, pode executar a seguinte consulta do Stackdriver. Tenha em atenção que esta ação só devolve registos de chamadas feitas a partir de fora da rede da GCP. Deve personalizá-lo conforme necessário para o 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 Notas

A Intel divulgou as seguintes CVEs:

Estas CVEs são coletivamente denominadas "Falha do terminal L1 (L1TF)".

Estas vulnerabilidades L1TF exploram a execução especulativa atacando a configuração das estruturas de dados ao nível do processador. "L1" refere-se à cache de dados de nível 1 (L1D), um pequeno recurso no núcleo usado para acelerar o acesso à memória.

Leia a publicação no blogue do Google Cloud para ver mais detalhes sobre estas vulnerabilidades e as mitigações do Compute Engine.

Impacto do Google Kubernetes Engine

A infraestrutura que executa o Kubernetes Engine e isola os clusters e os nós dos clientes uns dos outros está protegida contra ataques conhecidos.

Os node pools do Kubernetes Engine que usam a imagem do SO otimizado para contentores da Google e que têm a atualização automática ativada vão ser atualizados automaticamente para as versões corrigidas da nossa imagem do COS à medida que ficarem disponíveis a partir da semana de 20/08/2018.

Os node pools do Kubernetes Engine que não têm a atualização automática ativada têm de ser atualizados manualmente à medida que as versões corrigidas da nossa imagem do COS ficam disponíveis.

Alto

6 de agosto de 2018; última atualização: 5 de setembro de 2018

Descrição Gravidade Notas

Atualização de 05-09-2018

A vulnerabilidade CVE-2018-5391 foi divulgada recentemente. Tal como com a vulnerabilidade CVE-2018-5390, esta é uma vulnerabilidade de rede ao nível do kernel que aumenta a eficácia dos ataques de negação de serviço (DoS) contra sistemas vulneráveis. A principal diferença é que a CVE-2018-5391 é explorável através de ligações IP. Atualizámos este boletim para abranger ambas as vulnerabilidades.

Descrição

CVE-2018-5390 ("SegmentSmack") descreve uma vulnerabilidade de rede ao nível do kernel que aumenta a eficácia dos ataques de negação de serviço (DoS) contra sistemas vulneráveis através de ligações TCP.

CVE-2018-5391 ("FragmentSmack") descreve uma vulnerabilidade de rede ao nível do kernel que aumenta a eficácia dos ataques de negação de serviço (DoS) contra sistemas vulneráveis através de ligações IP.

Impacto do Google Kubernetes Engine

A partir de 11/08/2018, todos os mestres do Kubernetes Engine estão protegidos contra ambas as vulnerabilidades. Além disso, todos os clusters do Kubernetes Engine configurados para atualização automática também estão protegidos contra ambas as vulnerabilidades. Os node pools do Kubernetes Engine que não estão configurados para atualizar automaticamente, e foram atualizados manualmente pela última vez antes de 11/08/2018, são afetados por ambas as vulnerabilidades.

Versões com patches

Devido à gravidade desta vulnerabilidade, recomendamos que atualize manualmente os seus nós assim que o patch ficar disponível.

Alto

30 de maio de 2018

Descrição Gravidade Notas

Foi recentemente descoberta uma vulnerabilidade no Git que pode permitir a escalada de privilégios no Kubernetes se os utilizadores sem privilégios puderem criar pods com volumes gitRepo. A CVE é identificada com a etiqueta CVE-2018-11235.

Sou afetado?

Esta vulnerabilidade afeta-o se forem cumpridos todos os requisitos seguintes:

  • Os utilizadores não fidedignos podem criar pods (ou acionar a criação de pods).
  • Os pods criados por utilizadores não fidedignos têm restrições que impedem o acesso root do anfitrião (por exemplo, através de PodSecurityPolicy).
  • Os pods criados por utilizadores não fidedignos podem usar o tipo de volume gitRepo.

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

O que devo fazer?

Proíba a utilização do tipo de volume gitRepo. Para proibir volumes gitRepo com PodSecurityPolicy, omita gitRepo da lista de autorizações volumes na sua PodSecurityPolicy.

Pode alcançar um comportamento de volume gitRepo equivalente clonando um repositório git num volume EmptyDir a partir de um initContainer: 

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: {}

Que patch resolve esta vulnerabilidade?

Vai ser incluído um patch num próximo lançamento do Kubernetes Engine. Volte a consultar esta página para ver detalhes.

Médio

21 de maio de 2018

Descrição Gravidade Notas

Foram descobertas recentemente várias vulnerabilidades no kernel do Linux que podem permitir a escalada de privilégios ou a negação de serviço (através de uma falha do kernel) a partir de um processo sem privilégios. Estas CVEs são identificadas com as etiquetas CVE-2018-1000199, CVE-2018-8897, e CVE-2018-1087. Todos os nós do Kubernetes Engine são afetados por estas vulnerabilidades e recomendamos que atualize para a versão de patch mais recente, conforme detalhado abaixo.

O que devo fazer?

Para fazer a atualização, tem de atualizar primeiro o mestre para a versão mais recente. Esta correção está disponível no Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1 e Kubernetes Engine 1.10.2-gke.1. Estas versões incluem patches para imagens do SO otimizado para contentores e do Ubuntu.

Se criar um novo cluster antes disso, tem de especificar a versão corrigida para que seja usada. Os clientes que têm as atualizações automáticas de nós ativadas e que não fazem a atualização manual vão ter os respetivos nós atualizados para versões corrigidas nas próximas semanas.

Que vulnerabilidades são abordadas por esta correção?

A correção mitiga as seguintes vulnerabilidades:

CVE-2018-1000199: Esta vulnerabilidade afeta o kernel do Linux. Permite que um utilizador ou um processo sem privilégios falhe o kernel do sistema, o que leva a um ataque DoS ou a uma escalada de privilégios. Esta vulnerabilidade é classificada como Elevada, com um CVSS de 7,8.

CVE-2018-8897: Esta vulnerabilidade afeta o kernel do Linux. Permite que um utilizador ou um processo sem privilégios falhe o kernel do sistema, o que leva a um ataque DoS. Esta vulnerabilidade é classificada como Média, com um CVSS de 6,5.

CVE-2018-1087: Esta vulnerabilidade afeta o hipervisor KVM do kernel do Linux. Isto permite que um processo sem privilégios falhe o kernel do convidado ou, potencialmente, ganhe privilégios. Esta vulnerabilidade foi corrigida na infraestrutura em que o Kubernetes Engine é executado, pelo que o Kubernetes Engine não é afetado. Esta vulnerabilidade é classificada como Elevada, com uma pontuação CVSS de 8,0.

Alto

12 de março de 2018

Descrição Gravidade Notas

O projeto Kubernetes divulgou recentemente novas vulnerabilidades de segurança, CVE-2017-1002101 e CVE-2017-1002102, que permitem que os contentores acedam a ficheiros fora do contentor. Todos os nós do Kubernetes Engine são afetados por estas vulnerabilidades e recomendamos que faça a atualização para a versão de patch mais recente assim que possível, conforme detalhamos abaixo.

O que devo fazer?

Devido à gravidade destas vulnerabilidades, quer tenha ou não as atualizações automáticas de nós ativadas, recomendamos que atualize manualmente os seus nós assim que o patch ficar disponível. A correção vai estar disponível para todos os clientes até 16 de março, mas pode estar disponível mais cedo, com base na zona em que o cluster se encontra, de acordo com o calendário de lançamentos.

Para fazer a atualização, tem de atualizar primeiro o mestre para a versão mais recente. Esta correção vai estar disponível no Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 e Kubernetes 1.7.14-gke.1. Os novos clusters vão usar a versão corrigida por predefinição até 30 de março. Se criar um novo cluster antes dessa data, tem de especificar a versão corrigida para que seja usada.

Os clientes do Kubernetes Engine que tenham atualizações automáticas de nós ativadas e que não façam a atualização manual vão ter os respetivos nós atualizados para versões corrigidas até 23 de abril. No entanto, devido à natureza da vulnerabilidade, recomendamos que atualize manualmente os seus nós assim que o patch estiver disponível.

Que vulnerabilidades são abordadas por esta correção?

A correção mitiga as seguintes duas vulnerabilidades:

A vulnerabilidade CVE-2017-1002101 permite que os contentores que usam montagens de volume de subpath acedam a ficheiros fora do volume. Isto significa que, se estiver a bloquear o acesso do contentor a volumes hostpath com a PodSecurityPolicy, um atacante com a capacidade de atualizar ou criar pods pode montar qualquer hostpath através de qualquer outro tipo de volume.

A vulnerabilidade CVE-2017-1002102 permite que os contentores que usam determinados tipos de volumes, incluindo segredos, mapas de configuração, volumes projetados ou volumes de API descendente, eliminem ficheiros fora do volume. Isto significa que, se um contentor que use um destes tipos de volumes for comprometido ou se permitir que utilizadores não fidedignos criem pods, um atacante pode usar esse contentor para eliminar ficheiros arbitrários no anfitrião.

Para saber mais sobre a correção, leia a publicação no blogue do Kubernetes.

Alto

Boletins de segurança do Google Distributed Cloud

16 de outubro de 2019

Descrição Gravidade Notas

Foi recentemente descoberta uma vulnerabilidade no Kubernetes, descrita em CVE-2019-11253, que permite a qualquer utilizador autorizado a fazer pedidos POST executar um ataque de negação de serviço remoto num servidor da API Kubernetes. O Kubernetes Product Security Committee (PSC) divulgou informações adicionais sobre esta vulnerabilidade, que podem ser encontradas aqui.

Pode mitigar esta vulnerabilidade limitando os clientes que têm acesso à rede aos seus servidores da API Kubernetes.

O que devo fazer?

Recomendamos que atualize os seus clusters para uma versão de patch que contenha a correção assim que estiverem disponíveis.

As versões de patch que vão conter a correção estão listadas abaixo:

  • GKE Enterprise 1.1.1, que executa a versão 1.13.7-gke.30 do Kubernetes
Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade: CVE-2019-11253.

Alto

CVE-2019-11253

23 de agosto de 2019

Descrição Gravidade Notas

Descobrimos e mitigámos recentemente uma vulnerabilidade em que o proxy RBAC usado para proteger os pontos finais de monitorização não autorizava corretamente os utilizadores. Como resultado, as métricas de determinados componentes estão disponíveis para utilizadores não autorizados a partir da rede de cluster interno. 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 atualize os seus clusters para a versão 1.0.2-gke.3, que inclui a correção para esta vulnerabilidade, assim que possível.

Médio

Lançamentos do Google Distributed Cloud

22 de agosto de 2019

Descrição Gravidade Notas

O Kubernetes descobriu recentemente uma vulnerabilidade, CVE-2019-11247, que permite que as instâncias de recursos personalizados ao nível do cluster sejam tratadas como se fossem objetos com espaço de nomes existentes em todos os espaços de nomes. Isto significa que as contas de utilizador e de serviço com autorizações RBAC apenas ao nível do espaço de nomes podem interagir com recursos personalizados ao nível do cluster. A exploração desta vulnerabilidade requer que o atacante tenha privilégios para aceder ao recurso em qualquer espaço de nomes.

O que devo fazer?

Recomendamos que atualize os seus clusters para a versão 1.0.2-gke.3, que inclui a correção para esta vulnerabilidade, assim que possível.

Que vulnerabilidade é resolvida por esta correção?

A correção mitiga a seguinte vulnerabilidade: CVE-2019-11247.

Médio

CVE-2019-11247