No kit de ferramentas para gerenciar contêineres Docker Linux isolados vulnerabilidade (), que, sob um determinado conjunto de circunstâncias, permite acessar o ambiente host a partir de um contêiner se você tiver a capacidade de iniciar suas imagens no sistema ou com acesso a um contêiner em execução. O problema aparece em todas as versões do Docker e permanece sem solução (proposto, mas ainda não aceito, , que implementa a suspensão do contêiner durante a execução de operações com o FS).
A vulnerabilidade permite que arquivos sejam extraídos de um contêiner para uma parte arbitrária do sistema de arquivos do sistema host ao executar o comando “docker cp”. A extração de arquivos é realizada com direitos de root, o que possibilita a leitura ou gravação de qualquer arquivo no ambiente host, o que é suficiente para obter o controle do sistema host (por exemplo, você pode sobrescrever /etc/shadow).
O ataque só pode ser realizado quando o administrador executa o comando “docker cp” para copiar arquivos de ou para o contêiner. Assim, o invasor precisa de alguma forma convencer o administrador do Docker da necessidade de realizar esta operação e prever o caminho utilizado na cópia. Por outro lado, um ataque pode ser realizado, por exemplo, quando os serviços em nuvem fornecem ferramentas para copiar arquivos de configuração para um contêiner, construído através do comando “docker cp”.
O problema é causado por uma falha na aplicação da função , que calcula o caminho absoluto no sistema de arquivos principal com base no caminho relativo, levando em consideração o posicionamento do contêiner. Ao executar o comando "docker cp", um comando de curto prazo , em que o caminho já foi verificado, mas a operação ainda não foi realizada. Como a cópia é executada no contexto do sistema de arquivos principal do sistema host, dentro de um período de tempo especificado, você pode substituir o link por outro caminho e iniciar a cópia dos dados para um local arbitrário no sistema de arquivos fora do recipiente.
Como a janela de tempo para a ocorrência de uma condição de corrida é altamente limitada em um ambiente preparado, Ao realizar operações de cópia de um contêiner, foi possível obter um ataque bem-sucedido em menos de 1% dos casos ao substituir ciclicamente um link simbólico no caminho utilizado na operação de cópia (o ataque bem-sucedido foi realizado após aproximadamente 10 segundos de tentativas para copiar continuamente o arquivo em um loop com o comando “docker cp”).
Ao executar uma operação de cópia em um contêiner, você pode obter um ataque repetível de substituição de arquivo no sistema host em apenas algumas iterações. A possibilidade de ataque se deve ao fato de que ao copiar para um container, é utilizado o conceito “chrootarchive”, segundo o qual o processo archive.go extrai o arquivo não para o chroot da raiz do container, mas para o chroot do diretório pai do caminho de destino, controlado pelo invasor, e não interrompe a execução do contêiner (chroot é usado como um sinal para explorar condições de corrida).
Fonte: opennet.ru
