Falha HollowByte transforma servidores OpenSSL em alvo fácil para DDoS de baixa complexidade
Uma vulnerabilidade recentemente detalhada por pesquisadores da Okta, batizada de HollowByte, expõe servidores que utilizam OpenSSL a ataques de negação de serviço extremamente eficientes. Com um payload malicioso de apenas 11 bytes, um invasor não autenticado é capaz de provocar consumo anormal de memória, degradar o desempenho e, em muitos cenários, derrubar serviços críticos.
Embora o problema tenha sido corrigido de forma discreta pela equipe do OpenSSL, sem atribuição de identificador CVE, o impacto potencial é relevante, já que a biblioteca está presente em praticamente toda a infraestrutura moderna de TI, de servidores web a bancos de dados.
Como o ataque HollowByte explora o handshake TLS
Durante o estabelecimento de uma conexão TLS (o famoso “handshake”), cliente e servidor trocam uma série de mensagens estruturadas. Cada uma delas possui um cabeçalho de 4 bytes, responsável por informar o tamanho do conteúdo que virá em seguida.
Nas versões vulneráveis do OpenSSL, existe um comportamento perigoso: o servidor confia nesse valor do cabeçalho e realiza a alocação de memória com base no tamanho declarado antes de receber o payload completo e sem validar adequadamente se a quantidade de dados recebidos corresponde ao que foi anunciado.
O ataque HollowByte aproveita justamente essa confiança excessiva. O invasor envia um pacote de apenas 11 bytes, mas com um cabeçalho que indica um corpo de mensagem muito maior. Ao receber esse cabeçalho inflado, o OpenSSL reserva uma quantidade significativa de memória para tratar aquela conexão. Em seguida, o servidor fica bloqueado, aguardando por dados adicionais que nunca virão, deixando o thread ocupado e a memória alocada.
Por que a memória não volta ao normal mesmo após o ataque?
À primeira vista, pode parecer que o problema se resolveria automaticamente após o encerramento das conexões. De fato, o OpenSSL libera os buffers quando a sessão é finalizada. O ponto crítico está em como o sistema operacional e a biblioteca padrão lidam com essa memória.
Em sistemas Linux com a GNU C Library (glibc), pequenas e médias alocações de memória não são devolvidas ao sistema operacional imediatamente. Em vez disso, são mantidas para possível reutilização pelo próprio processo. Em circunstâncias normais, isso aumenta o desempenho. No contexto do HollowByte, porém, torna-se um vetor de ataque.
Ao disparar ondas sucessivas de conexões malformadas, com tamanhos declarados aleatórios e exagerados, o atacante força o alocador de memória a criar diversos blocos que, embora tecnicamente liberados mais tarde, não são reaproveitados de forma eficiente. O resultado é a fragmentação do heap e um aumento constante do Resident Set Size (RSS), métrica que reflete a quantidade de memória física efetivamente ocupada pelo processo.
Mesmo após o término do ataque, o processo servidor permanece “inchado” em termos de consumo de memória. Em muitos casos, a única forma de recuperar integralmente o espaço desperdiçado é reiniciando o serviço ou o processo afetado, o que implica indisponibilidade planejada em um contexto que já é crítico.
Alcance do problema: onde o OpenSSL está presente
O risco da HollowByte é amplificado pela onipresença do OpenSSL no ecossistema de TI. A biblioteca é usada:
– Em servidores web como NGINX e Apache, responsáveis por hospedar sites, APIs e aplicações corporativas.
– Em runtimes de linguagens de programação, como Node.js, Python, Ruby e PHP, que dependem do OpenSSL para estabelecer conexões TLS seguras.
– Em bancos de dados como MySQL e PostgreSQL, que utilizam TLS para proteger comunicação entre cliente e servidor.
– Em sistemas operacionais baseados em Linux, onde o OpenSSL geralmente vem pré-instalado para gerenciamento de certificados e criptografia.
Nos testes conduzidos pela equipe da Okta, ambientes de baixa capacidade – por exemplo, servidores com pouca memória ou instâncias menores em nuvem – tiveram seus recursos esgotados com relativa facilidade. Já servidores de grande porte, embora não derrubados de imediato, chegaram a perder cerca de 25% de memória disponível, tudo isso com tráfego de ataque permanecendo abaixo de muitos limiares de alerta de segurança, o que torna o ataque silencioso e difícil de detectar em um primeiro momento.
Como foi feita a correção no OpenSSL
O time responsável pelo OpenSSL revisou a lógica de alocação usada durante o handshake TLS. Nas versões corrigidas, o comportamento mudou de forma essencial: o buffer de recepção só cresce conforme os dados de fato chegam, em vez de seguir cegamente a declaração de tamanho contida no cabeçalho.
Na prática, isso significa que um atacante não consegue mais forçar, apenas com um cabeçalho inflado, uma reserva massiva de memória. O código passou a desconfiar das informações declaradas e a validar o volume de dados efetivamente recebido antes de expandir os buffers.
A correção foi introduzida na versão 4.0.1 do OpenSSL e posteriormente backportada para versões ainda amplamente usadas: 3.6.3, 3.5.7, 3.4.6 e 3.0.21. Essas versões passam a tratar o problema na origem, impedindo o padrão de alocação abusiva explorado pela HollowByte.
O que as organizações devem fazer agora
A principal recomendação é inequívoca: atualizar imediatamente os pacotes OpenSSL em todos os servidores e serviços que dependem da biblioteca. Em ambientes corporativos, isso inclui:
– Servidores web (incluindo balanceadores de carga e proxies reversos).
– Aplicações backend escritas em linguagens que usam OpenSSL por padrão.
– Servidores de banco de dados com suporte a TLS.
– Componentes internos que realizam comunicação criptografada entre microserviços.
Além da mera atualização, é fundamental revisar o ciclo de gestão de vulnerabilidades:
– Mapear onde o OpenSSL está instalado e em quais versões.
– Automatizar verificações de versão em pipeline de CI/CD e em ferramentas de inventário de ativos.
– Estabelecer janelas regulares de manutenção para aplicação de patches de segurança.
Medidas adicionais de mitigação e monitoramento
Mesmo após a atualização, vale fortalecer os controles de detecção e resposta para esse tipo de ameaça:
1. Monitoramento de memória:
Configurar alertas baseados em aumento anômalo e persistente de RSS em processos que utilizam TLS, como NGINX, Apache e servidores de aplicação.
2. Limitação de conexões suspeitas:
Ajustar limites de conexões simultâneas, timeouts de handshake TLS e uso de filas no servidor web ou proxy reverso, reduzindo a janela para threads bloqueados por muito tempo.
3. Proteção de borda:
Utilizar firewalls de aplicação, rate limiting e, quando disponível, serviços de mitigação de DDoS, capazes de identificar padrões de conexões incompletas ou malformadas.
4. Observabilidade de TLS:
Incluir métricas específicas de handshake TLS em painéis de observabilidade, permitindo que equipes detectem picos anormais de tentativas de conexão parcial.
Por que ataques como o HollowByte são especialmente perigosos
Ataques DDoS clássicos costumam depender de grandes volumes de tráfego ou de botnets extensas. A HollowByte segue outro caminho: busca a eficiência no uso de recursos e a exploração de falhas lógicas no código. Com poucos bytes enviados, é possível desencadear uma sequência de eventos que consome memória e threads de forma desproporcional.
Esse tipo de ataque é atraente para criminosos porque:
– Exige menos infraestrutura maliciosa para ser efetivo.
– Pode ser disparado a partir de um número reduzido de máquinas.
– Tem maior chance de passar despercebido em sistemas que só monitoram volume bruto de tráfego.
Além disso, como o impacto permanece mesmo após o fim do ataque (devido ao inchaço de memória persistente), a organização pode experimentar instabilidade prolongada, com queda gradual de desempenho e falhas intermitentes difíceis de diagnosticar.
Integração com políticas de segurança e compliance
Para empresas sujeitas a normas e padrões de segurança, como ISO 27001 ou equivalentes, a HollowByte reforça a importância de práticas maduras de gestão de mudanças e correção de vulnerabilidades. A falha evidencia que:
– Atualizações de componentes de base (como bibliotecas criptográficas) são tão críticas quanto patches de sistemas operacionais.
– É necessário manter inventários precisos de software de terceiros integrado às aplicações.
– Equipes de segurança e desenvolvimento devem atuar de forma integrada, garantindo que patches sejam testados e implantados com rapidez.
Incorporar esse tipo de vulnerabilidade nos exercícios de análise de risco e nos testes de resiliência (incluindo testes de carga e cenários de DDoS) ajuda a antecipar impactos e a definir planos de contingência.
Caminho para uma postura mais resiliente
A HollowByte não é apenas mais uma falha em uma longa lista de problemas de segurança. Ela ilustra como pequenos detalhes na implementação de protocolos críticos, como o TLS, podem abrir portas para ataques de grandes proporções.
Organizações que desejam se proteger não devem encarar esse caso como um incidente isolado, mas como um alerta para:
– Reforçar processos de atualização contínua.
– Investir em observabilidade detalhada de recursos.
– Promover revisão periódica de componentes críticos de segurança.
Ao combinar correções técnicas – como a atualização imediata para as versões corrigidas do OpenSSL – com práticas de governança e monitoramento, é possível reduzir significativamente a superfície de ataque e aumentar a resiliência diante de novas vulnerabilidades que, inevitavelmente, continuarão surgindo.