CVE-2020-15257

Resumo

containerd é um runtime de contêiner padrão da indústria e está disponível como um daemon para Linux e Windows. No containerd antes das versões 1.3.9 e 1.4.3, a API do containerd-shim é exposta indevidamente a contêineres de rede do host. Os controles de acesso para o socket da API do shim verificavam se o processo de conexão tinha um UID efetivo de 0, mas não restringiam de outra forma o acesso ao socket de domínio Unix abstrato. Isso permitiria que contêineres maliciosos executados no mesmo namespace de rede do shim, com um UID efetivo de 0, mas com privilégios reduzidos de outra forma, fizessem com que novos processos fossem executados com privilégios elevados. Esta vulnerabilidade foi corrigida no containerd 1.3.9 e 1.4.3. Os usuários devem atualizar para essas versões assim que forem lançadas. Deve-se notar que os contêineres iniciados com uma versão antiga do containerd-shim devem ser interrompidos e reiniciados, pois os contêineres em execução continuarão vulneráveis mesmo após uma atualização. Se você não está fornecendo a capacidade para usuários não confiáveis iniciarem contêineres no mesmo namespace de rede do shim (tipicamente o namespace de rede "host", por exemplo, com docker run --net=host ou hostNetwork: true em um pod Kubernetes) e executarem com um UID efetivo de 0, você não está vulnerável a este problema. Se você está executando contêineres com uma configuração vulnerável, você pode negar o acesso a todos os sockets abstratos com AppArmor adicionando uma linha semelhante a deny unix addr=@**, à sua política. É uma boa prática executar contêineres com um conjunto reduzido de privilégios, com um UID diferente de zero, e com namespaces isolados. Os mantenedores do containerd desaconselham fortemente o compartilhamento de namespaces com o host. Reduzir o conjunto de mecanismos de isolamento usados para um contêiner necessariamente aumenta os privilégios desse contêiner, independentemente de qual runtime de contêiner é usado para executá-lo.

• abstractshimmerPoC