Pesquisadores da equipe do Google Project Zero lançados recentemente por meio de uma postagem no blog um novo método de exploração de vulnerabilidades (CVE-2020-29661) na implementação do manipulador ioctl TIOCSPGRP do Subsistema tty do kernel Linux, bem como mecanismos de proteção detalhados que podem bloquear essas vulnerabilidades.
É mencionado na postagem que o problema é causado por um erro nas configurações de bloqueio, levando a uma condição de corrida no código de /tty/tty_jobctrl.c, que foi usado para criar condições para acessar a memória após o lançamento (use-after-free), explorado pelo espaço do usuário por meio da manipulação com ioct- chamando TIOCSPGRP.
Além das informações publicadas, também uma demonstração de exploração funcional foi realizada para escalonamento de privilégios em Debian 10 com kernel 4.19.0-13-amd64 e que também não exclui que pode afetar várias distribuições, entre as quais, é claro, estão aquelas baseadas e derivadas do Debian.
Muitas das técnicas de exploração individual e opções de mitigação que estou descrevendo aqui não são novas. No entanto, acho que vale a pena escrevê-los juntos para mostrar como várias mitigações interagem com um exploit pós-livre bastante normal.
Os trechos de código nesta postagem do blog que são relevantes para o exploit foram retirados da versão anterior 4.19.160, pois é nisso que o kernel do Debian de destino é baseado; alguns outros trechos de código são da linha principal do Linux.
Ao mesmo tempo, no artigo publicado, a ênfase não está tanto na técnica de criar um exploit funcional, mas em quais ferramentas lá no kernel para se proteger contra tais vulnerabilidades.
A conclusão é decepcionante, como é mencionado que métodos como segmentação de memória no heap e controle de acesso à memória depois de liberada não são aplicados na prática, pois levam à degradação do desempenho e proteção com base em CFI (Control Flow Integrity), que bloqueia exploits no último estágios de um ataque, requer melhorias.
Um tipo especial de dispositivo de terminal são os pseudoterminais, que são usados quando, por exemplo, você abre um aplicativo de terminal em um ambiente gráfico ou se conecta a uma máquina remota via SSH. Enquanto outros dispositivos terminais estão conectados a algum tipo de hardware, ambas as extremidades de um pseudoterminal são controladas pelo espaço do usuário e os pseudoterminais podem ser criados livremente pelo espaço do usuário (sem privilégios).
Sempre que / dev / ptmx é aberto (abreviação de "multiplexador de pseudo-terminal"), o descritor de arquivo resultante representa o lado do dispositivo (referido na documentação e nas fontes do kernel como "o pseudo-terminal mestre") de um dispositivo. Novo pseudo-terminal terminal.
O dispositivo de terminal correspondente (ao qual um shell normalmente se conecta) é criado automaticamente pelo kernel em / dev / pts / .
Ao olhar para o que pode fazer a diferença a longo prazo, a ênfase está no uso de analisadores estáticos avançados ou usando linguagens de memória segura como dialetos Rust e C com anotações estendidas (como C comprovado) para construir verificadores de status, bloqueios, objetos e ponteiros. Os métodos de proteção também mencionam a ativação do modo panic_on_oops, tornando as estruturas do kernel somente leitura e restringindo o acesso às chamadas do sistema por meio de mecanismos como o seccomp.
O erro que está causando o problema foi corrigido no kernel do Linux em 3 de dezembro do ano passado. O problema se manifesta em kernels anteriores à versão 5.9.13, mas a maioria das distribuições corrigiu o problema nas atualizações do pacote do kernel que foram oferecidas no ano passado.
Uma vulnerabilidade semelhante também é mencionada (CVE-2020-29660) que foi encontrada simultaneamente na implementação da chamada ioctl TIOCGSID, mas também foi removida em todos os lugares.
Finalmente Se você estiver interessado em saber mais sobre isso, você pode verificar os detalhes no link a seguir.