CVE-2022-1015 & CVE-2022-1026

Este README.md é uma tradução do blog do David. David encontrou os CVEs 1015 e 1016 no kernel do Linux. Você pode visitar a página web dele para ler o documento original.

Aqui estão suas redes sociais:

• Twitter
• Github

Uma análise das duas novas vulnerabilidades do Linux em nf_tables

Publicado em 2 de abril de 2022.

• CVE-2022-1015 permite realizar um acesso out-of-bounds (fora dos limites) causado por validações insuficientes de argumentos de entrada, pode resultar em execução remota de código e em escalada de privilégio local.
• CVE-2022-1016 está relacionado a uma inicialização pobre das variáveis alocadas na stack, o que pode ser usado para vazar uma ampla variedade de dados do kernel para o espaço do usuário (userspace).

Esses problemas deveriam ser exploráveis nas configurações padrão da versão mais recente do Ubuntu e do RHEL. Escrevi minha prova de conceito (PoC) do CVE-2022-1015 tendo como alvo a versão do kernel 5.16-rc3 do Arch Linux.

Este documento é direcionado a pessoas que tenham um conhecimento básico do kernel do Linux em termos de funcionalidade e segurança. Tentei tornar este documento amigável para pessoas que não tenham conhecimento com a stack de rede para torná-lo acessível a todos.

Aqui está um guia de leitura:

• Se você está aqui simplesmente para ler sobre a vulnerabilidade, comece na Seção 4
• Se você também quer um pouco de contexto sobre o subsistema do kernel, comece com a Seção 2
• Se você está interessado em um pouco mais de contexto adicional, leia todo o documento

1. Contexto

Em meados de fevereiro, o programa de segurança do Google anunciou que continuaria seu programa de recompensas kCTF, oferecendo recompensas que vão de US$ 31.337 até 91.337 dólares por um exploit no kernel do Linux que possa escalar privilégios para o usuário root a partir de processos sem privilégios em um sandbox do nsjail.

Sendo um pobre estudante, obviamente isso chamou minha atenção. Esta era a minha primeira vez procurando uma vulnerabilidade do "mundo real", mas em minhas aventuras jogando CTF com minha equipe, me familiarizei com o kernel do Linux em termos de segurança. Depois de horas e horas com muito pouco ou quase nenhum progresso (mas com maior conhecimento sobre Linux) consegui encontrar algumas vulnerabilidades no módulo nf_tables.

Tristemente, no final do dia, percebi que este módulo não estava presente nas regras do kCTF do Google (portanto, não consegui nenhuma recompensa por essas duas vulnerabilidades). Mas obviamente, ainda assim as reportei e escrevi um exploit LPE (Escalada de Privilégios Local) para o CVE-2022-1015.

1.1 Identificando o objetivo e a estratégia de auditoria

Bem, então você decidiu que vai encontrar algumas vulnerabilidades no Linux. E agora? O Linux é um projeto gigantesco, e é bastante fácil não conseguir ver a floresta por causa das árvores (você foca tanto nos detalhes que perde a visão do que é realmente importante, não tem uma visão geral da situação). Para piorar as coisas, muitas partes não são documentadas e você precisa ler um monte de código para entender o que está acontecendo.

Eu comecei tentando ter uma perspectiva detalhada do modelo de segurança do Linux. Encontrar um bug é uma coisa; mas encontrar um bom bug é outra bem diferente. Afinal, nem todos os bugs são criados iguais:

• Se um bug requer privilégios root, não existe um limite de segurança significativo (a menos que a kernel module signing esteja ativada)
  • Algumas coisas que vêm à mente são muitos dos módulos dos sistemas de arquivos (virtuais). Apenas o usuário root inicial pode montar esses sistemas de arquivos. A exceção está em vfe que especifica FS_USERNS_MOUNT, nesse caso você pode montá-los no user namespace.
• Se um bug não pode ser acessado através de chamadas de sistema, provavelmente não será explorável.
  • Isso se aplica a muitos drivers de hardware, já que você não tem acesso físico à máquina. Os drivers de rede de baixo nível ainda podem ser um bom alvo se você puder, p. ex., enviar dados via bluetooth ou 802.11.ac.
  • Obviamente isso depende do cenário em que você se encontra.
• Muitos bugs requerem CAP_SYS_ADMIN ou CAP_NET_ADMIN.
  • Os user namespaces (espaços de nomes) estão ativados por padrão, então isso não é um problema.
  • Caso contrário, primeiro você terá que fazer uma escalada de privilégios para o namespace (espaço de nomes) do usuário root dentro de um contêiner.
• Nem todos os módulos estarão presentes no seu alvo.
  • O Linux é um pedaço de software excepcionalmente altamente configurável, portanto todas as configurações podem variar de uma grande quantidade de formas.
  • A configuração do kernel geralmente pode ser acessada em /proc/config.gz. Os módulos podem ser carregados como (=m) ou compilados separadamente e carregados em tempo de execução (=y).
  • Você pode usar /proc/modules e /proc/kallsyms, mas nem sempre são confiáveis, pois os módulos podem ser carregados dinamicamente no kernel (p. ex. request_module).
  • Se você não tem certeza, escreva um pequeno programa que tente interagir com o módulo.

Essas restrições nos ajudam a conhecer os limites dos sistemas de arquivos nos quais podemos procurar vulnerabilidades. Acho que é uma boa ideia você dedicar seu tempo tentando planejar seu ataque ao alvo desejado.

Já aprendi minha lição sobre o ponto anterior. Como mencionei, o módulo nf_tables não estava carregado na instância que nos foi apresentada pelo kCTF. Eu poderia ter percebido isso desde o início e ter poupado a decepção :p. Por outro lado, provavelmente você não estaria lendo este blog agora se eu tivesse percebido antes, suponho que as coisas acabaram dando certo no final.

Uma explicação para o COS, fork do Linux otimizado para contêineres do Google, não ter nf_tables pode ser encontrada aqui e aqui.

1.2 nf_tables: por quê?

Depois de avaliar os pontos mencionados anteriormente, decidi que minha melhor rota para começar provavelmente seria olhar o código fonte da rede. Muitas das funcionalidades interessantes lá precisam de CAP_NET_ADMIN, mas como mencionei, isso na verdade não é um problema. Pelo contrário, suspeito que os componentes que requerem capacidades especiais são geralmente menos seguros, pois os desenvolvedores do kernel podem ter uma falsa sensação de segurança.

Também fiz o esforço de escolher o sistema de arquivos do qual queria saber mais; dessa forma, mesmo que você não encontre nenhum bug, ainda assim poderá aprender um monte de coisas interessantes.