
Análise do CVE-2017-1002101 com exemplo de "exploit"/escape
Após ouvir sobre o problema e seguir este guia, quis explorar as coisas um pouco mais. Este repositório contém algumas implantações de pods e scripts shell auxiliares que demonstram o mecanismo de ataque da forma mais simples possível, para que administradores e operadores do Kubernetes possam compreender totalmente a gravidade e os riscos potenciais. Você precisa ser um usuário autenticado ou ser capaz de controlar a especificação/modelo de um pod no momento da criação, então este escape provavelmente não será anônimo a menos que combinado com outros ataques como este.
Quando o Kubelet monta um volume/secret/configmap, etc., ele segue incorretamente links simbólicos dentro do volume para locais fora do escopo onde deveria. Como o Kubelet está sendo executado como root, isso significa que ele pode ser enganado para montar partes privilegiadas do sistema de arquivos do host dentro do contêiner de um pod não privilegiado. Minha abordagem foi usar um único pod com dois contêineres "normais". Um contêiner cria o link simbólico para / ou e o outro crashloop até que isso seja bem-sucedido (forçando o volume a ser remontado e seguindo esse caminho de link simbólico), permitindo que o usuário execute comandos no segundo contêiner e acesse o ponto de montagem.
/home/ubuntuNota: Estes exemplos funcionam sem modificação em um host Ubuntu 16.04, mas podem ser facilmente ajustados para outras configurações.
./run-as-root.sh se seu cluster for razoavelmente "padrão"../run-as-root-no-chroot.sh ou ./run-as-user-1000.sh para outras variações.É realmente uma situação de "correção obrigatória". Infelizmente, as soluções alternativas listadas aqui não são muito práticas para a maioria das pessoas. Quase todas as versões anteriores são vulneráveis.