Safe-Linking reforça alocadores de memória contra primitiva antiga de exploração em heap

Mecanismo protege listas simplesmente encadeadas usadas por malloc() e free() contra adulteração de ponteiros em cenários de overflow em heap sem vazamento prévio de endereço.

Componente	Listas simplesmente encadeadas em implementações de heap usadas por malloc() e free(), incluindo estruturas como Fast-Bins e TCache em bibliotecas como glibc e uClibc-NG.
Vetor	Adulteração de metadados de heap após uma vulnerabilidade inicial, como overflow linear em buffer de heap, para corromper ponteiros de chunks livres em listas simplesmente encadeadas.
Impacto	Sem proteção adicional, a corrupção do ponteiro pode transformar uma falha de escrita limitada em uma primitiva de alocação controlada em endereço escolhido, abrindo caminho para escrita arbitrária e execução de código conforme o contexto do processo vulnerável.
Prioridade	Priorizar versões de biblioteca que integrem Safe-Linking, revisar produtos embarcados baseados em uClibc-NG e tratar crashes de alocador, desalinhamento de chunks e corrupção de metadados como sinais de exploração ou tentativa de exploração.
Versões	glibc 2.3.6 já havia introduzido Safe-Unlinking em 2005 para listas duplamente encadeadas; Safe-Linking fecha a lacuna remanescente em listas simplesmente encadeadas e foi integrado a glibc e uClibc-NG.
Artefatos	A pesquisa usou como exemplo a CVE-2020-6007, uma vulnerabilidade de overflow em heap encontrada durante análise de lâmpadas inteligentes, em um cenário com implementação malloc-standard de uClibc em 32 bits.

Resumo técnico

Safe-Linking é uma mitigação para uma classe de exploração de heap que permaneceu relevante por quase duas décadas: a adulteração de ponteiros em listas simplesmente encadeadas mantidas por alocadores de memória. A técnica mira estruturas usadas por malloc() e free(), especialmente Fast-Bins e TCache, que armazenam chunks livres por meio de ponteiros simples. Quando uma aplicação tem uma falha inicial de escrita em heap, como um overflow linear de tamanho limitado, o invasor pode tentar modificar o ponteiro que conecta esses chunks e fazer o alocador tratar um endereço controlado como se fosse uma região livre legítima. O resultado técnico é uma primitiva de alocação em local escolhido, frequentemente descrita como Malloc-Where ou Arbitrary-Malloc, que pode ser encadeada com outras condições para obter escrita mais forte e, em certos programas, execução de código.

A mitigação parte de uma diferença histórica importante. Listas duplamente encadeadas já receberam proteção com Safe-Unlinking em glibc 2.3.6, lançada em 2005, por meio de verificações de integridade antes da remoção de nós. Esse mecanismo reduziu a viabilidade da técnica conhecida como Unsafe-Unlinking, na qual ponteiros FD e BK eram adulterados para induzir escrita arbitrária durante a operação de unlink. As listas simplesmente encadeadas, porém, continuaram expostas a outro padrão de ataque: em vez de abusar de dois ponteiros de encadeamento, o atacante tenta controlar o ponteiro único que aponta para o próximo chunk livre. Safe-Linking adiciona proteção a essa superfície ao combinar aleatoriedade derivada de ASLR com checagens de alinhamento de chunks, dificultando a substituição do ponteiro por um valor útil quando o atacante não conhece os bits aleatórios relevantes do heap.

A mudança foi projetada para ter baixo custo operacional. O mecanismo acrescenta uma pequena quantidade de instruções de montagem às rotinas de alocação e liberação: o contexto descreve acréscimo de 2 a 3 instruções para free() e de 3 a 4 para malloc(). Em medições com glibc em ambiente de 64 bits, o impacto não foi mensurável mesmo em testes com um bilhão de operações de alocação e liberação em uma vCPU no GCP. Em outra família de alocador, tcmalloc de gperftools, o pior caso observado foi 1,5% de overhead, com média de 0,02%. Para equipes de engenharia, o ponto central é que a defesa endurece uma primitiva explorável sem exigir uma alteração estrutural pesada no desenho do alocador.

Fluxo técnico

O fluxo de ataque começa com uma vulnerabilidade de memória capaz de escrever além do limite de um buffer em heap. O exemplo técnico descrito envolve a CVE-2020-6007, uma falha de overflow em heap encontrada durante pesquisa sobre lâmpadas inteligentes. No teste, o heap usava uma implementação simples derivada de dlmalloc, especificamente a implementação malloc-standard de uClibc em 32 bits. O layout explorável colocava um buffer controlado antes de um chunk já liberado e armazenado em um Fast-Bin. A escrita fora do limite permitia alterar metadados do chunk livre adjacente, incluindo campos usados pelo alocador para interpretar tamanho e encadeamento. Com isso, a lista de chunks livres podia ser corrompida para apontar para um endereço escolhido pelo atacante.

Depois da corrupção, uma sequência de alocações do tamanho correspondente ao Fast-Bin afetado força o alocador a percorrer a lista adulterada. Se o ponteiro falso for aceito, a biblioteca passa a acreditar que existe um chunk livre no endereço controlado. Isso entrega ao atacante uma alocação em uma região que não deveria ser retornada por malloc(). Em glibc, havia uma verificação adicional de tamanho do chunk para esse tipo de caminho; em uClibc-NG, o contexto descreve que essa verificação não estava presente, removendo uma limitação importante para a primitiva Malloc-Where. Esse detalhe é relevante para análise de produtos embarcados, pois bibliotecas menores ou adaptadas podem não carregar todas as defesas disponíveis em ambientes Linux tradicionais.

Safe-Linking muda esse caminho ao proteger o valor armazenado do ponteiro da lista. O mecanismo usa a aleatoriedade de ASLR associada à localização do heap, cuja base é randomizada em conjunto com mmap_base. O endereço onde o ponteiro da lista é armazenado, representado tecnicamente como L, é usado para derivar uma máscara. O ponteiro real, representado como P, é armazenado de forma protegida, com bits aleatórios posicionados sobre a parte menos significativa do valor codificado. Assim, um atacante que consegue escrever sobre o ponteiro, mas não possui vazamento do heap ou de ponteiros, não conhece a máscara necessária para produzir um valor protegido válido que revele o destino pretendido.

A segunda camada é a checagem de alinhamento. Chunks alocados no heap obedecem a alinhamento fixo: o texto descreve 8 bytes em muitas arquiteturas de 32 bits e 16 bytes em arquiteturas de 64 bits, com observação específica de que, em CPUs Intel, glibc mantém alinhamento de 0x10 bytes tanto em 32 quanto em 64 bits. Ao revelar um ponteiro protegido, o alocador valida se o endereço resultante está alinhado conforme a regra esperada. Em máquinas de 64 bits, essa verificação faz uma tentativa aleatória falhar em 15 de 16 casos. Mesmo isoladamente, a checagem de alinhamento bloqueia técnicas conhecidas que tentavam apontar Fast-Bins para ganchos internos de malloc() para alcançar execução de código.

Superfície afetada

A superfície principal envolve programas nativos que dependem de alocadores baseados em listas de chunks livres e que processam entrada controlada pelo usuário em caminhos onde uma falha de heap pode ocorrer. A mitigação é especialmente relevante para binários dependentes de posição, carregados sem ASLR próprio, mas com heap randomizado pelo sistema operacional. Nesse caso, antes do Safe-Linking, o atacante podia explorar endereços fixos do binário e depender apenas de controle limitado sobre alocações, sem precisar de vazamento de heap. Com a proteção, a exploração passa a exigir capacidade adicional de vazamento de ponteiro ou de endereço do heap, pois a adulteração cega do ponteiro tende a produzir valor inválido ou desalinhado.

Ambientes Linux e embarcados aparecem no centro da análise porque glibc é a biblioteca padrão mais comum em Linux, enquanto uClibc-NG é usada em cenários embarcados. A menção a lâmpadas inteligentes ilustra o risco em firmware e dispositivos conectados, nos quais bibliotecas compactas podem carregar decisões diferentes das bibliotecas de sistemas de uso geral. A existência de overflow em heap não significa automaticamente execução de código; o impacto depende de layout de memória, controle de entrada, sequência de alocações, presença de ASLR, disponibilidade de vazamento de ponteiro e verificações do alocador. O ponto defensivo é que a ausência de Safe-Linking mantém viável uma transformação técnica conhecida: de uma escrita limitada em heap para uma primitiva de alocação controlada.

Produtos que incorporam bibliotecas C em firmware, appliances, componentes de rede, agentes locais ou serviços escritos em C/C++ devem ser avaliados pelo alocador efetivamente embarcado, não apenas pelo sistema operacional declarado. O risco também alcança builds antigos, bibliotecas mantidas fora do ciclo de atualização da distribuição e ambientes onde a biblioteca padrão foi copiada para dentro de uma imagem de produto. Como o mecanismo foi integrado às bibliotecas citadas, a ação prática é mapear quais binários realmente vinculam versões com Safe-Linking e quais continuam dependentes de implementações sem essa proteção.

• Aplicações em C/C++ que processam entrada não confiável e usam malloc() e free() em caminhos sensíveis a overflow em heap.
• Fast-Bins, TCache e listas simplesmente encadeadas usadas para manter chunks livres em alocadores de heap.
• Dispositivos embarcados e firmware baseados em uClibc-NG ou em variantes compactas de biblioteca C.
• Binários dependentes de posição que ainda podem ter heap randomizado por ASLR, mas expõem endereços fixos no próprio executável.
• Ambientes onde uma falha como overflow em heap permite corromper metadados de chunk livre adjacente.

Hunting e telemetria

A detecção operacional deve procurar sintomas de corrupção de heap e tentativas de manipular listas livres, não apenas indicadores tradicionais de rede. Em sistemas com telemetria de endpoint, eventos de abort, crash ou finalização anormal próximos a rotinas de alocação e liberação merecem triagem quando ocorrem em processos expostos a dados externos. Mensagens de desalinhamento, inconsistência em metadados de heap, falha em verificação de chunk ou abort provocado por validação do alocador indicam que uma escrita indevida pode ter tocado estruturas internas. Quando Safe-Linking está presente, tentativas cegas de exploração podem se manifestar como ponteiros revelados inválidos ou desalinhados, causando interrupção antes da primitiva útil.

Para equipes de DFIR, o escopo inicial deve combinar análise de versão da biblioteca, inventário de binários afetados e revisão de crashes. A CVE-2020-6007 mostra que uma vulnerabilidade de produto pode depender de um detalhe de alocador para sair de simples overflow e avançar para primitiva mais poderosa. Por isso, relatórios de crash em parsing de entrada, em protocolos expostos, em processamento de arquivos ou em serviços de IoT devem ser correlacionados com o tipo de heap usado. A ausência de um exploit público no ambiente não elimina risco: a técnica descrita é uma primitiva de exploração, e o mesmo padrão pode ser adaptado a diferentes programas desde que o atacante controle o layout suficiente para corromper um chunk livre.

Em engenharia de produto, a telemetria útil inclui símbolos de stack trace envolvendo malloc(), free(), rotinas de cache de threads, manipulação de Fast-Bins, erros de alinhamento e falhas logo após sequência repetida de alocações de mesmo tamanho. Em ambientes embarcados com poucos logs, dumps de processo, contadores de watchdog e reinicializações inesperadas após entrada malformada podem ser os únicos sinais. O valor defensivo está em tratar essas ocorrências como possível corrupção de heap até prova em contrário, especialmente quando o processo recebe tráfego de rede, arquivos de usuário ou mensagens de controle.

• Crashes em processos nativos próximos a chamadas de malloc() ou free() após processamento de entrada externa.
• Erros de integridade, desalinhamento ou corrupção de metadados de heap em logs de runtime ou dumps de processo.
• Sequências anormais de alocações de mesmo tamanho antes de falhas, principalmente em caminhos de parsing.
• Firmware ou binários vinculados a versões antigas de glibc, uClibc, uClibc-NG ou implementações derivadas de dlmalloc.
• Falhas reproduzíveis apenas quando há entrada longa, estruturada ou parcialmente controlada, sinalizando overflow linear em heap.

Mitigação

A mitigação principal é usar versões de biblioteca que integrem Safe-Linking e garantir que o binário em produção esteja realmente vinculado à biblioteca atualizada. Em sistemas Linux tradicionais, isso depende do ciclo de atualização da distribuição e da reinicialização ou recarga dos processos afetados. Em firmware e produtos embarcados, o trabalho costuma exigir rebuild da imagem, validação da cadeia de toolchain e confirmação de que a biblioteca C final não foi substituída por uma cópia antiga no processo de empacotamento. O inventário deve registrar a implementação de alocador, a versão da biblioteca C e os componentes que processam entrada não confiável.

Safe-Linking não elimina todas as explorações de heap. O próprio desenho assume que um atacante sem vazamento de heap ou ponteiro terá dificuldade em produzir um ponteiro protegido válido, mas uma capacidade de vazamento pode reduzir a efetividade da máscara. Por isso, a defesa precisa combinar atualização do alocador com hardening de compilação, ASLR ativo, redução de binários dependentes de posição quando possível, validação rigorosa de entrada e correção da vulnerabilidade raiz. A proteção também não substitui análise de memória em desenvolvimento; ela aumenta o custo da exploração de uma classe específica de adulteração de listas simplesmente encadeadas.

A resposta a uma suspeita de exploração deve priorizar preservação de dumps, coleta de logs de crash, identificação da versão da biblioteca e isolamento de caminhos de entrada que acionam a falha. Quando houver produto embarcado afetado, a equipe deve comparar builds de laboratório e produção para confirmar se a mesma implementação de heap está presente. Testes de regressão devem cobrir alocações e liberações repetidas em tamanhos próximos aos Fast-Bins, além de entradas malformadas que historicamente atingiram parsers vulneráveis. A validação final deve confirmar que o alocador aborta de forma controlada diante de corrupção detectada e que a vulnerabilidade de escrita fora do limite foi corrigida, não apenas mascarada pela mitigação.

• Atualizar glibc ou uClibc-NG para versões que incluam Safe-Linking e confirmar o vínculo real dos binários em produção.
• Corrigir a falha raiz de memória, como overflow em heap, em vez de depender apenas da mitigação do alocador.
• Manter ASLR ativo e revisar binários dependentes de posição que deixam endereços estáticos úteis para exploração.
• Rebuildar firmware e imagens embarcadas com toolchain e biblioteca C atualizadas, validando o artefato final distribuído.
• Coletar dumps e logs de crashes de heap para diferenciar falha comum, tentativa de exploração e regressão introduzida por atualização.