Empresa de ponto de verificação Mecanismo de proteção Safe-Linking, que dificulta a criação de exploits que manipulam a definição ou modificação de ponteiros para buffers alocados ao executar uma chamada malloc. O Safe-Linking não bloqueia completamente a possibilidade de exploração de vulnerabilidades, mas com sobrecarga mínima complica significativamente a criação de certas categorias de exploits, pois além do buffer overflow explorável, é necessário encontrar outra vulnerabilidade que causa vazamento de informações sobre a colocação do heap na memória.
Patches implementando Safe-Linking foram preparados para Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) e Google TCMalloc, e também são propostos para atualizar a proteção no Chromium (em
Desde 2012, o Chromium já incorpora a técnica de proteção MaskPtr visando solucionar o mesmo problema, mas a solução da Checkpoint demonstra desempenho superior).
Patches sugeridos já foram aprovados para entrega na versão de agosto e o Safe-Linking será habilitado por padrão. uClibc-NG suporta link seguro incluído na versão 1.0.33 e está habilitado por padrão. Mudanças no gperftools (antigo tcmalloc) , mas será oferecido como opção em uma versão futura.
Desenvolvedores (novo tcmalloc) recusou-se a aceitar , citando grave degradação de desempenho e a necessidade de adicionar testes extensivos para verificar regularmente se tudo está funcionando conforme o esperado. Os testes dos engenheiros da Checkpoint mostraram que o método Safe-Linking não leva ao consumo adicional de memória e o desempenho ao realizar operações de heap é reduzido em média em apenas 0.02% e, na pior das hipóteses, em 1.5% (para comparação, a sobrecarga em o método usado no Chromium são estimados como “menos de 2%”). Inclusão
Safe-Linking resulta em 2-3 instruções de montagem adicionais sendo executadas cada vez que free() é chamado, e 3-4 instruções cada vez que malloc() é chamado. A execução dos estágios de inicialização e geração de valor aleatório não é necessária.
O Safe-Linking pode ser usado não apenas para melhorar a segurança de várias implementações de heap, mas também para adicionar controles de integridade a quaisquer estruturas de dados que usem listas de ponteiros vinculadas individualmente, colocadas próximas aos próprios buffers. O método é muito simples de implementar e requer apenas adicionar uma macro e aplicá-la aos ponteiros para o próximo bloco no código (por exemplo, para Glibc apenas algumas linhas de código). O método se resume às seguintes alterações:
+#define PROTECT_PTR(pos, ptr)\
+ ((__typeof (ptr)) ((((tamanho_t) pos) >> 12) ^ ((tamanho_t) ptr)))
+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
- próximop = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...
A essência do método é usar dados aleatórios do mecanismo de randomização de endereços ASLR (mmap_base) para proteger listas vinculadas individualmente, como Fast-Bins e TCache. Antes de o valor ser aplicado a um ponteiro para o próximo elemento da lista, ele executa uma conversão de máscara e verifica o alinhamento da página. O ponteiro é substituído pelo resultado da operação "(L >> PAGE_SHIFT) XOR (P)", onde P é o valor do ponteiro e L é o local da memória onde o ponteiro está armazenado.
Quando usado no sistema (Address Space Layout Randomization) parte 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 (extraído por uma operação de deslocamento de 12 bits para páginas de 4096 bytes). Essa manipulação reduz o risco de sequestro de ponteiro em uma exploração, uma vez que o ponteiro não é armazenado em sua forma original e sua substituição requer conhecimento da alocação de heap. Além disso, o código de patch também contém uma verificação adicional de alinhamento de bloco, que não permite que um invasor substitua um ponteiro por um valor desalinhado e requer conhecimento do número de bits alinhados, o que em sistemas de 64 bits permite adicionalmente o bloqueio 15 de 16 tentativas de ataque que não levam em conta o alinhamento.
O método é eficaz para proteção contra ataques que usam reescrita parcial de ponteiro (alteração de bytes baixos), reescrita completa de ponteiro (redirecionamento para o código do invasor) e alteração da posição da lista em um endereço não alinhado. Como exemplo, mostra-se que o uso do Safe-Linking no malloc permitiria bloquear a exploração recentemente pelos mesmos pesquisadores de vulnerabilidade na luz inteligente Philips Hue Bridge, causada por um estouro de buffer e permitindo que você obtenha o controle do dispositivo.
Fonte: opennet.ru