CVE-2014-0160

Falha de leitura fora dos limites (buffer over-read) na implementação da extensão TLS/DTLS Heartbeat (RFC 6520) do OpenSSL, que permite a um atacante remoto e não autenticado extrair até 64KB de memória de processo por requisição, repetidamente, sem deixar rastro necessário. Afeta qualquer serviço que use OpenSSL 1.0.1 até 1.0.1f para TLS/DTLS — o que inclui a maior parte da web em 2014 — e pode expor chaves privadas TLS, credenciais e dados de sessão em texto claro. É considerada uma das vulnerabilidades mais impactantes já divulgadas justamente pela combinação de trivialidade de exploração, ausência de autenticação e alcance (praticamente toda a internet HTTPS da época).

A extensão Heartbeat permite que um lado da conexão TLS/DTLS envie um payload arbitrário e um campo de comprimento declarado; o outro lado deve devolver exatamente esse payload como prova de que a conexão está viva. A falha está em d1_both.c (DTLS) e t1_lib.c (TLS): o código que processa o HeartbeatMessage confia no campo de comprimento informado pelo remetente sem validar que ele corresponde ao tamanho real do payload recebido. Isso é uma leitura fora dos limites — CWE-125.

O atacante envia um HeartbeatRequest com um payload minúsculo (por exemplo, 1 byte) mas declara um campo de comprimento de até 65.535 bytes (o máximo do campo de 16 bits do protocolo). O servidor (ou cliente) vulnerável aloca o buffer de resposta usando o comprimento declarado, copia o payload real mais o restante da memória adjacente ao buffer de heap onde ele residia, e devolve tudo ao atacante. Como a memória adjacente pode conter qualquer coisa alocada anteriormente pelo processo — chaves privadas TLS carregadas na inicialização, buffers de sessão, credenciais de autenticação básica, cookies de sessão, fragmentos de requisições de outros usuários — o atacante recebe até 64KB de memória de processo por chamada, sem limite no número de tentativas.

Não exige autenticação, não exige configuração não padrão, não exige interação do usuário e funciona antes mesmo da conclusão do handshake TLS em alguns casos (o heartbeat pode ser trocado durante o handshake). A falha é bidirecional: um cliente malicioso pode extrair memória de um servidor vulnerável, e um servidor malicioso (ou um MITM redirecionando um cliente) pode extrair memória de um cliente vulnerável — afetando VPNs, clientes de e-mail com STARTTLS, e qualquer aplicação que use libssl como cliente.

Exploração ativa em massa ocorreu nos dias seguintes à divulgação (abril de 2014); está no catálogo KEV da CISA, tem módulo Metasploit e múltiplas PoCs públicas (incluindo o script de Jared Stafford, referenciado em testes da época). O atacante não controla qual dado específico será retornado — o ataque é probabilístico, exigindo repetição para aumentar a chance de capturar segredos específicos como a chave privada RSA em uso.

A correção definitiva é atualizar para OpenSSL 1.0.1g (ou 1.0.2-beta2 para o ramo beta). Após a atualização, os serviços que usam a biblioteca (Apache, Nginx, servidores de e-mail, VPNs, etc.) precisam ser reiniciados — a atualização do pacote OpenSSL por si só não corrige processos já em execução, que continuam usando a biblioteca vulnerável carregada em memória.

Caso a atualização não seja imediatamente possível, um paliativo real é recompilar o OpenSSL com a flag -DOPENSSL_NO_HEARTBEATS, desabilitando a extensão heartbeat inteiramente (custo: perda da funcionalidade de keep-alive do heartbeat, sem impacto funcional relevante na maioria dos casos, já que é usada primariamente para manter conexões DTLS vivas). Independentemente da via de correção, qualquer sistema exposto que estava rodando versão vulnerável deve ser tratado como comprometido: revogar e regerar certificados TLS, trocar chaves privadas, forçar reset de credenciais de usuários e invalidar sessões ativas — porque não há como provar retroativamente que a chave não foi extraída antes da correção.

Usar Perfect Forward Secrecy (PFS) reduz o dano de uma chave de sessão vazada (não permite decriptar tráfego passado capturado), mas não protege a chave privada do certificado nem tickets de sessão TLS já emitidos — não é substituto para a troca de chaves. Trocar apenas o certificado sem gerar um novo par de chaves não mitiga nada, já que a chave privada comprometida permanece a mesma.

É possível detectar tentativas de exploração inspecionando o tráfego de rede: uma resposta de heartbeat (TLS record type 0x18) com tamanho declarado muito maior que o esperado para uma requisição legítima é o indicador central. Assinaturas Snort/Suricata publicadas na época (por exemplo, pela Fox-IT) comparam o tamanho do heartbeat de resposta contra faixas suspeitas (e.g., acima de 200 bytes até o limite de ~16KB por registro TLS) para sinalizar respostas anormalmente grandes.

Não há sinal confiável para detectar exploração retroativa antes da implantação dessas assinaturas — o ataque não deixa rastro no lado do servidor além do tráfego de rede em si (não gera erro de aplicação, não aparece em logs de aplicação), o que motivou a orientação de tratar qualquer serviço exposto como potencialmente comprometido, independentemente de haver evidência de ataque nos logs.