Nota perev. : Na noite passada, Aleksa Sarai, engenheiro sênior de contêineres do SUSE Linux, contou à lista de discussão oss-sec uma vulnerabilidade crítica de segurança runc / LXC que poderia permitir que um invasor com acesso a um contêiner isolado ganhasse privilégios de root no sistema host. Como o problema foi identificado na implementação de referência do tempo de execução do contêiner - runc -, ele afeta vários sistemas de contêineres, incluindo Docker / Moby, Podman , cri-o (e o próprio Kubernetes). Os detalhes são apresentados abaixo na forma de tradução da mensagem de um engenheiro em uma lista de endereçamento.Sou um dos mantenedores de runc (o tempo de execução do contêiner subjacente usado pelo Docker, cri-o, container, Kubernetes etc.). Recentemente, tornou-se conhecido sobre uma vulnerabilidade que verificamos e corrigimos.
Pesquisadores que descobriram a vulnerabilidade:
- Adam Iwaniuk;
- Borys Popławski.
Além disso, Aleksa Sarai (ou seja, I) descobriu que o LXC também é afetado por uma versão mais sofisticada dessa vulnerabilidade.
Breve revisão
A vulnerabilidade permite que um contêiner mal-intencionado (com interação mínima do usuário) substitua o binário do host runc e, portanto, possa executar código com privilégios de root no host. O grau de interação do usuário é tal que permite executar qualquer comando (não importa se o invasor controla o comando) com privilégios de root no contêiner em qualquer um destes contextos:
- Criando um novo contêiner a partir de uma imagem controlada por um invasor;
- Conexão (
docker exec ) a um contêiner existente ao qual o invasor anteriormente tinha acesso de gravação.
Esta vulnerabilidade
não é
bloqueada pela política padrão do AppArmor ou pela política padrão do SELinux no Fedora * (porque os processos do contêiner parecem ter iniciado com o
container_runtime_t ). No entanto, ele é
bloqueado pelo uso correto de espaços para nome de usuário (onde a raiz do host não é mapeada para o espaço para nome de usuário do contêiner).
O vetor CVSSv3 (com uma classificação de 7,2) é o seguinte:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HO
problema foi atribuído
CVE-2019-5736 .
* O problema se aplica apenas ao pacote moby-engine no Fedora. O pacote docker , como o podman , é protegido de sua operação, pois inicia os processos de container_t como container_t .Patches
Estou aplicando o patch apropriado para corrigir o problema (
0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch ). É baseado no ramo
HEAD , embora o código no
libcontainer/nsenter/ mude tão raramente que o patch provavelmente se aplique a quase qualquer versão antiga da base de código runc com a qual você está lidando.
Observe que o
patch que eu envio à ramificação master runc é uma versão modificada desse patch, embora eles sejam funcionalmente idênticos (se você ainda não corrigiu seus arquivos com o patch anexado, recomendamos o uso da versão upstream).
Código de exploração secundária
Alguns fornecedores solicitaram um código de exploração para garantir que os patches resolvessem o problema. Como o problema é muito sério (especialmente para fornecedores de nuvem pública), decidimos fornecer esse código. A exploração que escrevi é mais geral do que o código original fornecido pelos pesquisadores e funciona para o LXC (não requer grandes modificações para poder ser aplicado a outros ambientes executáveis vulneráveis). Detalhes sobre como usar o código de exploração são fornecidos no
README .
De acordo com as regras do OpenWall, o código de exploração será divulgado
publicamente 7 dias após o CRD (ou seja, 18 de fevereiro de 2019).
Se você tiver um tempo de execução do contêiner, verifique se ele não é afetado por esta vulnerabilidade.Impacto em outros projetos
Deve-se notar que, no curso de uma investigação mais aprofundada do problema, descobri que o LXC tem uma vulnerabilidade semelhante e eles já enviaram um
patch semelhante
ao nosso desenvolvimento conjunto. O LXC é um pouco mais difícil de operar, mas o problema em si é o mesmo.
Uma discussão com representantes do systemd-nspawn levou à conclusão de que eles não são vulneráveis (uma vez que possuem um método diferente de conectar-se ao contêiner para LXC e runc).
Os representantes do Apache Mesos também entraram em contato comigo, relatando que eles também são vulneráveis (acho que eles simplesmente usaram o código de exploração que será publicado). É muito provável que a maioria dos tempos de execução do contêiner seja vulnerável se eles não tiverem tomado medidas muito incomuns para mitigar seu impacto potencial.
Outras notícias
Criamos um boletim informativo para futuras vulnerabilidades de segurança: o processo para ingressá-lo é descrito
aqui (é baseado na lista de distribuição de anúncios de segurança do Kubernetes). Inscreva-se se você distribuir quaisquer tempos de execução para contêineres que dependem de runc (ou outros projetos OCI).
PS Do tradutor
Problema CVE-2019-5736 nos rastreadores de distribuições populares do Linux:
... e a
postagem do blog Kubernetes (consulte a seção "O que devo fazer?").