Uma vulnerabilidade no io_uring permitiu que um usuário sem permissões se tornasse root mesmo em contêineres

Faz pouco informações de vulnerabilidade divulgadas (CVE-2022-29582) na implementação da interface de E/S assíncrona io_uring, incluída no kernel Linux desde a versão 5.1, que permite que um usuário sem privilégios se torne root no sistema, mesmo ao executar um exploit de container.

Cabe mencionar que disse que a vulnerabilidade foi relatada há pouco mais de 3 meses (aproximadamente no início de maio deste ano), mas as informações e divulgação completas só foram divulgadas recentemente.

Em relação à vulnerabilidade, menciona-se que esta ocorre ao acessar um bloco de memória já liberado, se manifesta nos kernels do Linux a partir da ramificação 5.10.

Sobre a vulnerabilidade CVE-2022-29582

Esta vulnerabilidade permite acesso à memória liberada como resultado de uma condição de corrida ao manipular tempos limite na função io_flush_timeouts(), quee remove a entrada de tempo limite da lista e a cancela, sem verificar a criação e exclusão do tempo limite naquele momento.

Uma descrição geral atualizada de io_uring já foi fornecida por outros. Eles explicam isso mil vezes melhor do que nós, então vamos cobrir o subsistema mais extensivamente (veja este artigo Grapl Security e este artigo Flatt Security para uma ótima introdução).

O que é mais importante, o campo opcode determina o tipo de operação a ser executada. Para cada "opcode" que o requer, o campo fd especifica o descritor de arquivo no qual executar a E/S solicitada. Quase todas as chamadas de sistema de E/S normais (read, sendto, etc.) têm um opcode assíncrono equivalente. Cada campo pode assumir diferentes funções, dependendo da operação.

Uma vez recuperado do SQ, um SQE é convertido em uma representação interna descrita por struct io_kiocb(retorno de chamada de entrada/saída do kernel). Esses objetos são comumente conhecidos como solicitações.

struct io_kiocb é usado como um equivalente ao SQE "ready-for-launch" no qual se baseia, em que qualquer descritor de arquivo é resolvido para struct file*s, as credenciais do usuário são anexadas, a personalidade (em que os núcleos serão executados), etc. .

Após a conclusão da operação solicitada, ela é gravada na fila de conclusão (CQ) uma entrada que corresponde ao SQE. Essa entrada é chamada de entrada da fila de conclusão (CQE) e contém campos como um código de erro e um valor de resultado. O aplicativo de espaço do usuário pode sondar o CQ para novas entradas para determinar se os SQEs enviados concluíram o processamento e qual foi o resultado.

É mencionado que existem alguns cenários em que é fácil substituir um objeto sobre a marcha. Mas há duas limitações:

  • LT' deve ser atribuído e inicializado em uma janela de corrida. Ou seja, após o LT ser liberado, mas antes de chegar a um ponto do LT que não é mais acessado.
  • LT' só pode ser outro objeto struct io_kiocb. Devido ao isolamento do heap, onde os objetos no heap são separados de acordo com seu tipo, é muito difícil reatribuí-los como um tipo diferente de objeto dentro da janela de corrida.

Pesquisadores prepararam um exploit funcional que não requer a inclusão de namespaces de identificador de usuário (namespaces de usuário) para sua operação e pode fornecer acesso root ao host quando um usuário sem privilégios inicia a exploração em um contêiner isolado.

Nossa exploração tem como alvo a versão 5.10.90 do kernel, a versão que o Google estava executando remotamente na época. Tivemos que ajustar nosso exploit para as especificações particulares do servidor (4 núcleos Skylake Xeon @ 2.80Ghz, 16GiB RAM), mas com alguns ajustes, qualquer máquina rodando um kernel vulnerável deveria ser explorável.

O exploit também funciona no ambiente nsjail isolado na distribuição do Google COS (Container Optimized OS) com base no Chromium OS e usado no Google Cloud Platform em máquinas virtuais do Compute Engine. O exploit foi projetado para funcionar com ramificações do kernel de 5.10 a 5.12. Por último, vale mencionar que o problema corrigido em abril nas atualizações 5.10.111, 5.15.34 e 5.17.3.

Por fim, se estiver interessado em saber mais sobre a vulnerabilidade, pode consultar a publicação feita no link a seguir.


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: AB Internet Networks 2008 SL
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.