Uma vulnerabilidade batizada de HollowByte permite que atacantes sem autenticação provoquem uma condição de negação de serviço, ou DoS, em servidores OpenSSL com um payload malicioso de apenas 11 bytes.
A equipe do OpenSSL corrigiu o problema em junho, sem atribuir um CVE, sem comunicado e sem entrada no changelog indicando a falha, e também levou o patch para versões mais antigas. As versões corrigidas são OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 e 3.0.21, todas datadas de 9 de junho. Todas as versões anteriores nessas linhas estão vulneráveis.
Como o OpenSSL é uma base essencial para a comunicação segura na internet, organizações devem priorizar a atualização para uma versão corrigida da biblioteca.
A equipe de Red Team da Okta, que reportou a falha de negação de serviço e deu nome ao ataque, publicou os detalhes nesta quinta-feira. Em um aviso divulgado no início desta semana, os pesquisadores descreveram como a vulnerabilidade HollowByte funciona e qual é seu impacto em um cenário real.
Os pesquisadores explicam que, em um handshake de TLS, cada mensagem traz um cabeçalho de 4 bytes para informar o tamanho da mensagem que está chegando. Cada mensagem de handshake de TLS começa com um cabeçalho de 4 bytes, no qual um campo de 3 bytes indica o tamanho dos dados de handshake que devem vir em seguida.
No entanto, nas versões vulneráveis do OpenSSL, o sistema aloca a quantidade declarada antes de receber o conteúdo e verificar seu tamanho. Sem validar o payload, o servidor confia na informação do pacote e reserva a memória indicada.
Em versões mais antigas, o OpenSSL ampliava o buffer de recepção para esse tamanho assim que o cabeçalho chegava, antes de qualquer byte do corpo aparecer e antes de as verificações próprias do handshake serem executadas. No caso de um ClientHello de entrada, o limite é de 131 KB.
“A thread de trabalho então fica bloqueada, esperando indefinidamente por dados que nunca vão chegar”, explica a Okta.
Um atacante sem autenticação pode acionar o HollowByte ao abrir uma conexão TLS e enviar uma entrada maliciosa de 11 bytes com um cabeçalho que afirma que um corpo de mensagem muito maior virá depois. Onze bytes bastam para fazer um servidor OpenSSL sem patch reservar até 131 KB de memória para uma mensagem que nunca chega.
O agressor repete o mesmo processo em várias conexões, fazendo o servidor alocar grandes volumes de memória com uma quantidade relativamente pequena de dados transmitidos. Sem autenticação, sem sessão e sem troca de chaves.
Os pesquisadores da Okta observam que, embora o OpenSSL libere os buffers quando uma conexão cai, a GNU C Library, ou glibc, trata a memória de forma diferente e “não devolve imediatamente ao sistema operacional as alocações pequenas e médias; ela as mantém para possível reutilização”.
Em sistemas glibc testados pela Okta, essa memória não é liberada até que o processo seja reiniciado.
“Ao lançar ondas de conexões com tamanhos declarados aleatórios, o atacante impede que o alocador reutilize esses blocos liberados”, diz a Okta.
“O heap fica fortemente fragmentado, fazendo o Resident Set Size, ou RSS, do servidor subir continuamente.
Mesmo depois que o atacante se desconecta, o servidor permanece permanentemente inchado.”
A única forma de recuperar totalmente o espaço é reiniciando o processo.
A biblioteca open source OpenSSL está integrada a projetos populares, como os servidores web NGINX e Apache, runtimes de linguagem, como Node.js, Python, Ruby e PHP, além de bancos de dados como MySQL e PostgreSQL. Ela já vem instalada na maioria das distribuições Linux para criptografia TLS e tratamento de certificados.
Nos testes da Okta no NGINX, ambientes de baixa capacidade tiveram a memória esgotada com facilidade usando o HollowByte, enquanto servidores mais robustos podem perder até 25% da memória, com o tráfego do ataque ainda abaixo dos limites que normalmente acionariam alertas de segurança.
Nos testes com NGINX da Okta, um servidor com 1 GB foi encerrado pelo OOM killer com 547 MB de memória presos em fragmentos. Em um servidor de 16 GB, o HollowByte travou 25% da memória do sistema sem sequer ultrapassar o teto por conexão, motivo pelo qual a equipe de Red Team afirma que “defesas padrão de limitação de conexões não vão impedir isso”.
Embora falhas de DoS sejam consideradas menos graves do que vulnerabilidades que permitem roubo de dados ou execução de código, elas podem causar interrupções operacionais e danos à reputação. O HollowByte se diferencia por persistir: o heap se fragmenta, o conjunto residente de memória cresce e permanece alto muito tempo depois de o atacante desaparecer.
Sozinha, essa seria uma ataque de exaustão de conexões, algo tão antigo quanto o Slowloris. O que faz o HollowByte persistir é a glibc.
A correção do HollowByte foi lançada em junho pela OpenSSL sem CVE, sem comunicado e sem entrada no changelog indicando o problema. A release também fechou 18 CVEs, incluindo uma falha de use-after-free de severidade High em PKCS7_verify(), de modo que quem usa uma dessas versões upstream já recebeu a correção, ainda que sem aviso específico sobre ela.
Apesar de ter sido tratado como uma “correção de hardening” e não como uma vulnerabilidade de segurança, a Okta recomenda “atualizar imediatamente os pacotes OpenSSL da sua distribuição”.
A OpenSSL não explicou o motivo. Em um fluxo de patch normal, nada aponta para a falha: não há identificador para um scanner reconhecer nem comunicado para consultar.
Foi pedido à OpenSSL uma explicação sobre por que o HollowByte foi classificado abaixo de Low e se a correção chegou às linhas 1.1.1 e 1.0.2, de suporte estendido. Também perguntou à Okta se a fragmentação persiste em alocadores além da glibc. A reportagem será atualizada se houver resposta.
A linha do projeto é mais fina do que parece. Em janeiro, a OpenSSL atribuiu o
CVE-2025-66199
, classificado como Low, a uma falha de compressão de certificado no TLS 1.3, na qual um tamanho fornecido pelo par fazia um buffer de heap crescer antes da validação, gerando algo em torno de 22 MiB por conexão.
Aquele caso exigia quatro condições ao mesmo tempo: compressão de certificado compilada, um algoritmo de compressão disponível, a extensão negociada e, em servidores, certificados de cliente solicitados. O HollowByte não precisa de nenhuma delas.
Na mesma versão lançada em 9 de junho, a OpenSSL atribuiu o
CVE-2026-34183
, classificado como Moderate, ao crescimento ilimitado de memória no manipulador QUIC PATH_CHALLENGE. Ambos são ataques de negação de serviço por exaustão de memória. Ambos receberam identificadores.
No ecossistema downstream, a situação é pior. O padrão documentado da Red Hat é aplicar backports em vez de trocar a versão, então um pacote corrigido continua informando a versão a partir da qual foi construído. Normalmente, isso é resolvido por meio do comunicado e do feed OVAL, ambos vinculados a nomes de CVE. Aqui, não há CVE para servir de referência.
Resta verificar o changelog do pacote ou perguntar ao mantenedor se ele fez rebase para a versão de 9 de junho ou se aplicou o patch, que é o pull request 30792 para master e 4.0, 30793 para 3.6, 3.5 e 3.4, e 30794 para 3.0. Quem compila o OpenSSL por conta própria deve atualizar para a versão listada e reiniciar tudo o que carregou a biblioteca antiga.
A correção cobre apenas TLS. Caswell escreveu no pull request que o DTLS foi deixado de lado porque a implementação correta exigiria mudanças muito mais invasivas e o projeto decidiu não mexer nisso por enquanto.
Foi comparado o código-fonte da OpenSSL nas tags 3.6.2 e 3.6.3 e encontrou o arquivo de handshake do DTLS idêntico, byte por byte, após a correção. Na 4.0.1, a versão mais recente, esse caminho ainda dimensiona o buffer com base no tamanho declarado pelo par.
A OpenSSL não classificou esse caminho nem se comprometeu a corrigi-lo. As release notes, o changelog e a página de vulnerabilidades não dizem nada sobre isso. O pull request, sim.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...