Glibc: buffer overflow in ld.so leading to privilege escalation

Buffer overflow no dynamic loader (ld.so) da glibc ao processar a variável de ambiente GLIBC_TUNABLES, batizada de 'Looney Tunables' pela Qualys, que a descobriu e publicou a análise. Permite escalonamento de privilégios local: um usuário sem privilégios que execute um binário SUID/SGID com essa variável manipulada pode obter root. A falha é séria porque quase todo binário SUID (su, sudo, mount, passwd, etc.) serve de vetor, e distribuições Linux mainstream com glibc >= 2.34 rodam esse código por padrão — não depende de configuração exótica.

O bug está na rotina que faz o parse da string passada em GLIBC_TUNABLES antes de o loader ativar o binário SUID. O parser processa pares chave=valor separados por dois-pontos e, ao validar o tamanho/conteúdo dos tunables, escreve fora dos limites do buffer alocado — um out-of-bounds write (CWE-787/CWE-120) em memória heap do processo do próprio dynamic loader, que roda com os privilégios elevados do binário SUID antes mesmo do código da aplicação começar a executar.

Segundo a análise da Qualys, a falha foi introduzida em abril de 2021, quando um commit reescreveu a lógica de filtragem de tunables herdados via ambiente para binários AT_SECURE (SUID/SGID), e chegou ao release glibc 2.34. Versões anteriores ao 2.34 não contêm esse trecho de código e, portanto, não são vulneráveis ao mecanismo descrito — mesmo que apareçam listadas em rastreadores de produto por dependência genérica do componente glibc.

O atacante controla integralmente o conteúdo de GLIBC_TUNABLES no ambiente do processo que ele mesmo lança. Como ld.so processa essa variável antes de dropar privilégios ou aplicar qualquer sandboxing da aplicação, o overflow ocorre num contexto já privilegiado (owner do binário SUID), o que torna a corrupção de memória diretamente aproveitável para controle de fluxo.

Pré-requisito real: acesso local (shell) na máquina, sem necessidade de privilégio algum (PR:L no vetor CVSS reflete apenas a necessidade de poder executar processos, não privilégio elevado) e sem interação de terceiros. O atacante define a variável GLIBC_TUNABLES no ambiente e invoca qualquer binário instalado com bit SUID que use a glibc afetada — não é preciso vulnerabilidade adicional na aplicação SUID em si, o overflow acontece dentro do próprio ld.so antes de o binário-alvo executar sua lógica.

A Qualys publicou análise técnica detalhada e demonstrou exploração funcional, obtendo root completo em distribuições como Fedora, Ubuntu e Debian com glibc vulnerável, sem divulgar o exploit weaponizado no primeiro momento; PoCs públicas e um módulo Metasploit surgiram depois, reduzindo bastante a barreira de exploração. A CISA incluiu a CVE no catálogo KEV citando exploração confirmada, o que eleva a prioridade de patch mesmo em ambientes sem exposição à internet, já que o vetor é local e serve como etapa de pós-exploração após qualquer acesso inicial (shell de baixo privilégio via outra falha, credencial roubada, container mal configurado com escape parcial etc.).

O resultado final é execução de código com privilégios de root (ou do dono do SUID), sem depender de condição de corrida ou timing preciso — a complexidade de exploração é considerada baixa uma vez compreendido o layout de memória do parser afetado.

Aplicar a atualização de pacote glibc do fornecedor da distribuição é a correção definitiva. Para RHEL, a Red Hat publicou correção em RHSA-2023:5453 (RHEL 9), RHSA-2023:5454 (RHEL 9.0 EUS), RHSA-2023:5455 (RHEL 8) e RHSA-2023:5476 (RHEL 8.6 EUS), com pacotes como glibc-2.34-28.el9_0.4 (RHEL 9.0 EUS), glibc-2.28-225.el8_8.6 (RHEL 8) e glibc-2.28-189.6.el8_6 (RHEL 8.6 EUS). Após instalar o pacote corrigido, é necessário reiniciar todos os serviços vinculados à glibc ou reiniciar o sistema — o advisory da Red Hat destaca isso explicitamente, já que processos já em execução continuam usando a versão antiga carregada em memória.

Como paliativo, se o patch não puder ser aplicado imediatamente: remover ou reduzir a superfície de binários com bit SUID desnecessários no sistema, e monitorar/filtrar a variável de ambiente GLIBC_TUNABLES via PAM ou wrapper de execução para processos privilegiados, mas isso é mitigação incompleta e frágil — não cobre todos os caminhos de invocação e não substitui o patch. Definir GLIBC_TUNABLES vazia no ambiente global não é garantia, porque o atacante controla o próprio ambiente do processo que lança o binário SUID.

O que não funciona: restringir acesso de rede ou colocar WAF na frente de alguma aplicação não tem efeito, já que a exploração é inteiramente local, dentro do processo — não há componente de rede na cadeia de ataque.

Não há assinatura de rede a procurar — a exploração é inteiramente local, dentro do processo que carrega o binário SUID. O sinal mais confiável é auditoria de execução de processos (auditd, EDR/HIDS) capturando execve de binários SUID com a variável de ambiente GLIBC_TUNABLES presente e com valores anômalos (strings longas, caracteres de controle, múltiplos separadores ':' fora do padrão esperado de tunables legítimos), especialmente quando o processo pai não é um shell de administração esperado. Crash ou comportamento anômalo (segfault) em binários SUID comuns como su, sudo, passwd, mount também é indício de tentativa de exploração falha, mas ambientes sem logging de linha de comando/variáveis de ambiente detalhado dificilmente terão visibilidade retroativa confiável.