Falha HollowByte permite DDoS em servidores OpenSSL com payload mínimo
Pesquisadores de segurança da Okta trouxeram à tona uma vulnerabilidade crítica no ecossistema OpenSSL, batizada de HollowByte, que abre espaço para ataques de negação de serviço (DoS / DDoS) contra servidores que utilizam a biblioteca. O mais alarmante: todo o ataque pode ser disparado com um payload malicioso de apenas 11 bytes, suficiente para provocar consumo anormal de memória e, em muitos casos, exaurir os recursos do servidor.
A brecha foi silenciosamente corrigida pela equipe do OpenSSL, sem direito a identificador CVE público, mas o impacto potencial é amplo, já que a biblioteca está presente em servidores web, bancos de dados, runtimes de linguagens e na maioria das distribuições Linux modernas.
Como o ataque HollowByte funciona
Durante o handshake TLS – a etapa inicial em que servidor e cliente negociam parâmetros de criptografia – cada mensagem enviada possui um cabeçalho de 4 bytes. Esse cabeçalho informa ao lado receptor qual é o tamanho do corpo da mensagem que está por vir.
Nas versões vulneráveis, o OpenSSL confia cegamente nesse valor declarado: ele reserva (aloca) em memória a quantidade de bytes informada no cabeçalho antes mesmo de receber o restante do payload e sem verificar se aquele tamanho faz sentido. Não há, nesse ponto, uma validação robusta dos dados.
O atacante se aproveita disso enviando um payload real minúsculo – apenas 11 bytes – acompanhado de um cabeçalho que declara um corpo de mensagem muito maior. O servidor, acreditando na informação do cabeçalho, reserva um bloco de memória desproporcional à quantidade real de dados. Em seguida, o thread de trabalho fica bloqueado, aguardando indefinidamente que o restante dos dados chegue, o que nunca acontece.
Ao repetir esse processo em diversas conexões simultâneas, o invasor faz com que o servidor aloque grandes quantidades de memória para múltiplos handshakes “ociosos”, criando as condições ideais para uma negação de serviço.
Impacto na memória e comportamento do sistema
À primeira vista, pode parecer que o problema se resolve sozinho quando a conexão é encerrada: o OpenSSL de fato libera os buffers associados à sessão. No entanto, entra em cena um comportamento específico da GNU C Library (glibc), amplamente utilizada em sistemas Linux.
A glibc não devolve de forma imediata ao sistema operacional as alocações de memória pequenas e médias que foram liberadas. Em vez disso, ela mantém esses blocos em cache interno para reutilização futura. Em condições normais, isso melhora o desempenho, pois evita realocações constantes. Porém, no cenário criado pelo HollowByte, essa característica se transforma em um problema.
Ao disparar ondas de conexões com tamanhos declarados aleatórios e exagerados, o invasor provoca uma fragmentação crescente do heap. A consequência é que o alocador de memória passa a ter dificuldade em reutilizar os blocos liberados de maneira eficiente. O resultado prático é o aumento contínuo do Resident Set Size (RSS), a métrica que indica quanta memória física o processo está de fato ocupando.
Mesmo depois que o atacante interrompe as conexões, o processo do servidor permanece “inchado”: a memória não volta ao patamar anterior. Em muitos ambientes, a única forma de recuperar totalmente o espaço consumido é reiniciar o processo (como o serviço do servidor web ou do banco de dados), o que pode gerar indisponibilidade adicional.
Quem é afetado pela HollowByte
O OpenSSL está embutido em grande parte da infraestrutura de TI atual. A biblioteca é componente central para:
– Servidores web como NGINX e Apache
– Runtimes de linguagens de programação amplamente usadas (Node.js, Python, Ruby, PHP)
– Bancos de dados populares, como MySQL e PostgreSQL
– Ferramentas e serviços de sistema que dependem de TLS e certificados digitais
Além disso, muitas distribuições Linux já incluem o OpenSSL por padrão para qualquer tarefa relacionada à criptografia, comunicação segura e manipulação de certificados.
Nos testes realizados pela equipe da Okta em ambientes com NGINX, servidores com poucos recursos de memória se mostraram particularmente vulneráveis: bastam poucas conexões maliciosas para consumir praticamente toda a RAM disponível. Em máquinas mais robustas, a situação também é grave: mesmo que não chegue à exaustão total, foi observada perda de até 25% da memória, enquanto o volume de tráfego malicioso permanece discreto, muitas vezes abaixo dos limiares dos sistemas de alerta.
Isso significa que um ataque bem planejado pode causar degradação significativa de performance ou indisponibilidade parcial, sem necessariamente disparar alarmes imediatos em ferramentas de monitoramento tradicionais.
Correções já disponíveis no OpenSSL
Diante da gravidade do problema, a equipe de desenvolvimento do OpenSSL implementou uma correção que altera o comportamento da biblioteca durante o handshake TLS. Em vez de confiar cegamente no valor declarado no cabeçalho, o código atualizado só expande o buffer à medida que os dados reais vão chegando, ignorando tamanhos inflados artificialmente.
Essa solução foi incorporada oficialmente na versão 4.0.1 do OpenSSL e também recebeu backport para versões anteriores amplamente utilizadas em produção:
– 3.6.3
– 3.5.7
– 3.4.6
– 3.0.21
Organizações que utilizam qualquer release anterior a esses números podem estar expostas à HollowByte e precisam considerar uma atualização urgente.
Recomendações para empresas e equipes de TI
A Okta recomenda fortemente que todas as organizações façam um inventário de onde o OpenSSL está sendo utilizado em sua infraestrutura, o que inclui:
– Servidores web de front-end e APIs
– Bancos de dados internos e externos
– Serviços de autenticação, proxies reversos e balanceadores de carga
– Aplicações customizadas que utilizam TLS diretamente
Uma vez mapeados os componentes, é essencial:
1. Atualizar os pacotes do OpenSSL das distribuições Linux para as versões corrigidas ou superiores.
2. Reiniciar os serviços que dependem da biblioteca após a atualização, garantindo que o processo passe a rodar com o código novo.
3. Revisar configurações de limites de conexão e uso de memória em servidores web e bancos de dados, como mitigação adicional contra picos de consumo.
4. Monitorar métricas como RSS, uso de heap e número de conexões TLS em estados iniciais de handshake, para detectar comportamentos anômalos.
Por que esse tipo de falha é tão perigoso
Vulnerabilidades como a HollowByte são especialmente preocupantes porque exploram o próprio desenho de componentes fundamentais do ecossistema de internet, e não apenas erros pontuais de configuração. Ataques de negação de serviço baseados em exaustão de memória costumam ser mais difíceis de detectar do que DDoS volumétricos clássicos, que sobrecarregam a banda de rede.
Além disso, o fato de o payload necessário ser extremamente pequeno (11 bytes) torna o ataque barato do ponto de vista do atacante. Com poucas requisições bem construídas, é possível causar impacto desproporcional, o que atrai tanto criminosos comuns quanto operadores mais sofisticados interessados em derrubar serviços de maneira furtiva.
Outro ponto crítico é a persistência do efeito: mesmo após o ataque cessar, o servidor pode continuar com consumo de memória anormal até ser explicitamente reiniciado. Em ambientes de alta disponibilidade, isso complica a resposta a incidentes, exigindo planejamento cuidadoso para não afetar ainda mais os usuários finais.
Como integrar a correção ao seu plano de segurança
Tratar a HollowByte apenas como um “patch a ser aplicado” é um risco. Ela precisa ser incorporada a uma estratégia mais ampla de gestão de vulnerabilidades e hardening de infraestrutura. Algumas boas práticas incluem:
– Estabelecer processos regulares de atualização de bibliotecas de criptografia e componentes de base do sistema.
– Automatizar varreduras que verifiquem versões de OpenSSL em servidores e containers, integrando isso ao pipeline de DevOps.
– Criar playbooks de resposta a incidentes que incluam análise de uso de memória, reinício controlado de serviços e comunicação com áreas de negócio quando for necessário realizar janelas de manutenção emergenciais.
Equipes de segurança também devem considerar testes de estresse específicos, simulando cenários de múltiplos handshakes TLS incompletos, para validar se a infraestrutura atual é capaz de detectar e suportar padrões de ataque semelhantes.
HollowByte no contexto do aumento das fraudes e ataques digitais
O surgimento de falhas como a HollowByte ocorre em um cenário em que ataques digitais estão se tornando mais frequentes e sofisticados. Criminosos aproveitam qualquer brecha em componentes amplamente utilizados para maximizar o alcance de suas ações. Tecnologias de inteligência artificial, automação de ataques e o uso de infraestruturas distribuídas tornam cada vez mais fácil disparar campanhas coordenadas de exploração.
Ao mesmo tempo, cresce a pressão para que empresas adotem padrões robustos de segurança da informação, certificações e frameworks de governança. Organizações com operações críticas, como provedores de serviços em nuvem, instituições financeiras, empresas de saúde e de infraestrutura, precisam tratar vulnerabilidades de base, como as que afetam o OpenSSL, como prioridade absoluta.
Próximos passos para proteger sua infraestrutura
Para reduzir o risco associado à HollowByte e a falhas semelhantes, é recomendável que as organizações:
– Atualizem imediatamente o OpenSSL para as versões corrigidas em todos os ambientes (produção, homologação e desenvolvimento).
– Implementem monitoramento proativo de uso de memória em processos que expõem serviços TLS.
– Reforcem camadas adicionais de proteção, como WAFs, rate limiting e controle de acesso em nível de rede.
– Mantenham uma política clara de gestão de patches, com prazos definidos para correção de vulnerabilidades críticas.
– Capacitem equipes de desenvolvimento e operações para entender os riscos de depender de bibliotecas desatualizadas.
A HollowByte deixa um recado claro: mesmo componentes consolidados e amplamente auditados, como o OpenSSL, podem esconder comportamentos que só se revelam em cenários específicos de ataque. Manter a infraestrutura segura depende não apenas de tecnologia, mas de processos maduros, visibilidade contínua e capacidade de resposta rápida quando novas falhas vêm à tona.