initstring/lxd_rootLinux privilege escalation via LXD
Membros do grupo local lxd em sistemas Linux têm várias formas de escalar seus privilégios para root. Este repositório contém exemplos de explorações locais de root totalmente automatizadas. Uma explicação detalhada da vulnerabilidade e um passo a passo da exploração estão disponíveis no meu blog aqui.
As explorações abaixo não são fugas de contêineres, mas sim explorações locais de root que aproveitam contêineres e visam o sistema operacional host. É necessário acesso de baixo privilégio ao ambiente host para uma exploração bem-sucedida.
Acredito que minha estratégia com a versão 2 da exploração seja única e foi interessante o suficiente (pelo menos para mim) para escrever uma explicação detalhada no blog linkado acima.
lxd_rootv1.sh monta o sistema de arquivos / do host em um contêiner, onde o usuário de baixo privilégio do host tem acesso root. Esse acesso root é mapeado de volta para o host, permitindo que o usuário atual seja adicionado ao arquivo /etc/sudoers. Isso já foi explorado por outros antes de mim.lxd_rootv2.py monta o socket UNIX privado do systemd do host em um contêiner e depois de volta ao host novamente através de dispositivos proxy LXD. Esses dispositivos proxy têm privilégios root e passam suas credenciais durante as comunicações do socket, ao contrário das credenciais do usuário de baixo privilégio iniciador. Isso é abusado para criar um serviço systemd temporário que adiciona o usuário atual ao arquivo /etc/sudoers.Ambas as explorações requerem um contêiner, então crie um primeiro. Em seguida, execute a exploração a partir do sistema operacional host com o nome do contêiner como o primeiro argumento.
# Exploit with v1
$ bash lxd_rootv1.sh <container name>
# Exploit with v2
$ python3 lxd_rootv2.py <container name>
Antes de me deparar com esses problemas, não existia nada na documentação oficial do LXD para alertar os usuários de que o grupo lxd era perigoso. Qualquer um seguindo as diretrizes oficiais para configurar o LXD teria adicionado sua conta a este grupo antes de implantar seu primeiro contêiner. Abri um bug com a Canonical para expressar minhas preocupações - você pode ler a thread completa aqui. A equipe do LXD rapidamente fez ajustes na documentação, que agora afirma claramente que este grupo só deve ser dado àqueles com acesso root confiável.
Como sempre, interagir com o pessoal da Canonical através do rastreador de bugs foi uma experiência realmente agradável. Gostaria de agradecer pelo tempo e pela consideração cuidadosa que deram às minhas ideias. Recomendo fortemente que outros pesquisadores de segurança levem itens diretamente a eles dessa maneira.
Não sou a primeira pessoa a explorar o LXD. Isso foi levantado como uma preocupação em vários tickets do GitHub datando de 2016:
Esse primeiro link é a primeira pessoa (simpoir) a identificar esse risco, pelo que posso dizer.
@reboare escreveu um ótimo blog sobre explorar o LXD usando o mesmo método da minha exploração v1, muito antes de mim:
Agradeço ao pessoal do LXD por fazer uma ferramenta muito legal. Eu pessoalmente uso o LXD e realmente gosto. Não acho que isso seja um impeditivo para usar o LXD, acho que é muito importante entender o risco potencial ao adicionar usuários ao grupo lxd.
Não há correção oficial para nenhuma dessas vulnerabilidades. Qualquer pessoa que use LXD deve estar ciente de que adicionar usuários ao grupo lxd é essencialmente transformá-los em root.
Se você estiver usando LXD em um host de um único usuário, como um desktop, pode ser melhor simplesmente não usar o grupo lxd e executar sudo quando precisar falar com a API.
Para ambientes compartilhados com várias pessoas trabalhando em contêineres, pode ser melhor criar ambientes aninhados. Cada usuário individual do grupo LXD será capaz de explorar seu próprio ambiente, mas terá que trabalhar mais para quebrar esse contêiner para explorar os outros.