Ponto de verificação (um provedor global de soluções de segurança de TI) lançado há vários dias, a introdução do mecanismo de segurança "Safe-Linking", que torna difícil criar exploits que manipulam a definição ou mudança de ponteiros para buffers alocados ao fazer uma chamada malloc.
O novo mecanismo «Safe-Linking» não bloqueia completamente a possibilidade de explorar vulnerabilidades, mas com sobrecarga mínima complica a criação de certas categorias de exploitsPois, além do estouro de buffer explorado, é necessário encontrar outra vulnerabilidade que cause informações sobre a localização do heap na memória.
Patches de implementação de Safe-Linking foram preparados para Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) e Google TCMalloc, bem como uma proposta para modernizar a proteção em Chromium (desde 2012 o Chromium já foi integrado com soluções para o mesmo problema) técnica de proteção MaskPtr, mas a solução da Checkpoint apresenta melhor desempenho).
Os patches propostos já foram aprovados para entrega na versão de agosto do Glibc 3.32 e o Safe-Linking será habilitado por padrão. No uClibc-NG, o suporte de link seguro foi incluído na versão 1.0.33 e está habilitado por padrão. No gperftools (antigo tcmalloc) as alterações são aceitas, mas serão oferecidas como uma opção em uma versão futura.
Os desenvolvedores TCMalloc se recusaram a aceitar a mudança, ccom forte desempenho de sucesso e a necessidade de adicionar testes avançados para verificar regularmente se tudo está funcionando corretamente.
Testes realizados por Os engenheiros do ponto de verificação mostraram que o método Safe-Linking não leva a um consumo adicional de memória e o desempenho ao realizar operações de heap em média diminui apenas 0.02% e, no pior caso, 1.5%
A ativação do Safe-Linking leva à execução de 2-3 instruções adicionais do assembler com cada chamada para free () e 3-4 instruções ao chamar malloc (). O início da inicialização e a geração de valor aleatório não são necessários.
O Safe-Linking pode ser usado não apenas para aumentar a segurança de várias implementações de heap, sino também para adicionar verificações de integridade a qualquer estrutura de dados que usa uma lista de ponteiros vinculados individualmente localizados próximos aos buffers.
O método é muito simples de implementar e requer apenas a adição de uma macro e aplique-o aos ponteiros para o próximo bloco do código (por exemplo, para Glibc, apenas algumas linhas são alteradas no código).
A essência do método é aplicar dados aleatórios do mecanismo de randomização de endereço ASLR (mmap_base) para proteger listas vinculadas individualmente, como Fast-Bins e TCache. Antes de aplicar o valor do ponteiro ao próximo item na lista, a conversão da máscara e a verificação do alinhamento são realizadas ao longo da borda da página de memória. O ponteiro é substituído pelo resultado da operação "(L >> PAGE_SHIFT) XOR (P)", onde P é o valor do ponteiro e L é o local na memória onde este ponteiro está armazenado.
Quando usado no sistema ASLR (Address Space Layout Randomization), alguns dos L bits com o endereço base do heap contêm valores aleatórios que são usados como uma chave para codificar P (eles são extraídos por uma operação de deslocamento de 12 bits para páginas de 4096 bytes).
Tal manipulação reduz o risco de capturar um ponteiro em um exploit, uma vez que o ponteiro não está armazenado em sua forma original e para substituí-lo, você precisa saber informações sobre a localização do heap.
O método é eficaz na proteção contra ataques que usam redefinição parcial do ponteiro (baixo deslocamento de byte), reescrita completa de ponteiros (redirecionar para o código do invasor) e reposicionar a lista em uma direção não alinhada.
Como exemplo, é mostrado que o uso de Safe-Linking em malloc bloquearia a exploração da vulnerabilidade CVE-2020-6007 recentemente descoberta pelos mesmos pesquisadores na luz de fundo inteligente Philips Hue Bridge causada pelo estouro de buffer e permitindo o controle o dispositivo.
fonte: https://research.checkpoint.com