Uma nova vulnerabilidade de segurança descoberta na biblioteca criptográfica OpenSSL, apelidada de "HollowByte", permite que atacantes remotos e não autenticados desencadeiem uma condição de negação de serviço (DoS) utilizando um payload malicioso de apenas 11 bytes. A falha foi identificada pela equipe de Red Team da Okta e explora a forma como o OpenSSL pré-aloca memória durante o handshake TLS, forçando servidores a reservar grandes blocos de memória antes mesmo de qualquer autenticação ocorrer.
Descoberta e escopo
O OpenSSL é um componente fundamental da infraestrutura da internet, sustentando uma vasta gama de servidores web, runtimes de linguagem e bancos de dados. A vulnerabilidade HollowByte foi descoberta por pesquisadores da Okta Red Team, que notaram um comportamento anômalo na alocação de memória durante o processo de handshake TLS. Diferente de ataques de DoS tradicionais que dependem de esgotamento de conexões, como o Slowloris, o HollowByte combina esgotamento de conexões com um problema de fragmentação de memória enraizado na forma como o glibc gerencia a memória liberada.
Quando uma conexão de ataque é encerrada, o OpenSSL libera o buffer, mas o glibc não retorna imediatamente as alocações pequenas e médias ao sistema operacional; ele as retém para reutilização potencial. Ao lançar ondas de conexões com tamanhos reivindicados aleatórios, os atacantes impedem que o alocador reutilize esses blocos liberados, fazendo com que o Resident Set Size (RSS) do servidor suba continuamente e permanentemente, mesmo após o atacante se desconectar. A única solução é matar o processo.
Como a vulnerabilidade funciona
Cada handshake TLS começa com uma mensagem ClientHello envolvida em um registro que carrega um cabeçalho de 4 bytes que declara o tamanho do corpo da mensagem de entrada. Em versões mais antigas do OpenSSL, a biblioteca aloca um buffer de recebimento baseado puramente no comprimento declarado pelo atacante antes de qualquer dado real chegar. Quando um payload fabricado de 11 bytes aterrissa, a máquina de estados TLS lê o cabeçalho e dispara a seguinte cadeia de alocação não validada:
- Ler Cabeçalho → grow_init_buf() → OPENSSL_clear_realloc() → malloc(attacker_size)
Como nenhuma validação ocorre nesta etapa, um único pacote malicioso pode forçar o malloc() a alocar até 131 KB com base apenas na reivindicação do atacante. A thread de trabalho então bloqueia indefinidamente, aguardando dados que nunca chegam.
Impacto operacional e testes
Os testes da Okta Red Team em instâncias não corrigidas do OpenSSL executando NGINX revelaram consequências severas. Em um ambiente de 1 GB de RAM, o servidor foi OOM-killed (Out of Memory) após acumular 547 MB de memória congelada e fragmentada. Em um ambiente de 16 GB de RAM, o ataque travou 25% da memória total do sistema enquanto permanecia sob os tetos padrão de conexão, o que significa que as defesas típicas de limitação de conexão falham em detê-lo.
Porque o OpenSSL está na base de uma vasta faixa de infraestrutura de internet, o raio de explosão da vulnerabilidade se estende a servidores web como Apache e NGINX, runtimes de linguagem incluindo Node.js, Python, Ruby e PHP, e bancos de dados como MySQL e PostgreSQL.
Correção e versões afetadas
O OpenSSL resolveu o problema mudando para um crescimento incremental de buffer, mesclado via pull requests #30792, #30793 e #30794. Em vez de confiar na reivindicação do cabeçalho diretamente, o OpenSSL agora expande o buffer apenas conforme os bytes realmente chegam na rede, o que significa que uma reivindicação vazia não custa nada ao servidor. A correção foi incorporada silenciosamente no OpenSSL v4.0.1, com backports silenciosos para 3.6.3, 3.5.7, 3.4.6 e 3.0.21.
Notavelmente, o OpenSSL tratou isso como uma melhoria de endurecimento em vez de emitir um aviso de CVE formal, um padrão visto em outras divulgações recentes do OpenSSL onde problemas de classe DoS são abordados sem designações de CVE de alto perfil. Como o HollowByte recebeu tratamento de patch silencioso em vez de um CVE, muitas organizações podem não sinalizá-lo através de varreduras de vulnerabilidade padrão.
Recomendações para equipes de segurança
Devido à ubiquidade do OpenSSL em servidores web, runtimes e bancos de dados, as equipes de segurança devem tratar isso como um patch de prioridade independentemente do status de CVE. As medidas recomendadas incluem:
- Atualizar para OpenSSL 4.0.1 ou a versão backport relevante (3.6.3, 3.5.7, 3.4.6 ou 3.0.21) imediatamente.
- Auditar versões do OpenSSL embutidas em runtimes de linguagem (Node.js, Python, Ruby, PHP), pois patches de nível de sistema operacional sozinhos não corrigirão cópias embutidas.
- Monitorar tendências de memória RSS em servidores de término TLS para sinais de inchamento de memória gradual e inexplicável consistente com ataques de fragmentação.
A ausência de um CVE formal pode levar a uma falsa sensação de segurança em ferramentas de gerenciamento de vulnerabilidades que dependem de listas de CVE para priorização. Administradores de sistemas devem verificar as notas de versão do OpenSSL e aplicar patches de segurança proativamente, especialmente em ambientes que lidam com alto tráfego TLS.