Skip to content

O "Sangramento" da Internet: Entendendo a Vulnerabilidade Heartbleed (CVE-2014-0160)

O que é o OpenSSL?

Antes de entendermos a falha, precisamos entender a ferramenta. O OpenSSL é uma biblioteca de software de código aberto (open-source) que atua como o "motor" de segurança de grande parte da internet.

Sempre que você acessa um site seguro (repare no cadeado ou no https:// na barra de endereços), ou quando projetos e dispositivos IoT se comunicam de forma criptografada com um servidor central, há uma grande chance de o OpenSSL estar trabalhando nos bastidores.

Ele opera na Camada 4 (Transporte) do modelo de redes, implementando os protocolos TLS (Transport Layer Security) e seu predecessor, o SSL (Secure Sockets Layer). Sua função principal é criar um "túnel seguro", garantindo que os dados transmitidos não possam ser interceptados ou lidos em texto plano por terceiros no meio do caminho.

O bug na biblioteca

Em abril de 2014, o mundo da cibersegurança parou. Uma vulnerabilidade crítica foi anunciada não em um software obscuro, mas justamente no OpenSSL, que era usado por cerca de dois terços de todos os servidores ativos na internet na época.

Batizada de Heartbleed (Sangramento do Coração), essa falha permitia que qualquer atacante roubasse senhas, mensagens privadas e até mesmo as chaves criptográficas mestras de gigantes como Yahoo, GitHub e serviços bancários, sem deixar absolutamente nenhum rastro nos logs do sistema.

Para entender como um erro de programação tão pequeno causou um estrago tão grande, precisamos entender como esses servidores mantêm suas conexões "vivas".

1. O Protocolo Heartbeat

Estabelecer uma conexão segura via TLS exige bastante processamento computacional. Para evitar ter que refazer todo o "handshake" de segurança caso a conexão fique ociosa, a extensão Heartbeat (RFC 6520) foi criada.

Ela funciona como um teste de eco simples para checar se o servidor do outro lado ainda está acordado:

  1. O cliente envia um pacote contendo uma palavra (payload) e o tamanho dessa palavra.
  2. O servidor recebe o pacote, aloca um espaço na memória, copia a exata mesma palavra para esse espaço e a envia de volta ao cliente.

A Analogia do Eco Normal:

  • Cliente diz: "Servidor, repita a palavra 'BOLA'. Ela tem 4 letras."
  • Servidor escuta: Lê as 4 letras (B-O-L-A).
  • Servidor responde: "BOLA".

Tudo funciona perfeitamente, desde que as pessoas digam a verdade.

2. A Anatomia do Bug: A Falta de Validação (Bounds Check)

O erro catastrófico no código fonte do OpenSSL foi a confiança cega. Os programadores escreveram o código para processar a mensagem baseando-se apenas no tamanho declarado pelo cliente, sem nunca verificar se a palavra enviada realmente tinha aquele tamanho.

Veja a essência do código original em C que causou o problema: 

/* O servidor lê o tamanho declarado pelo cliente e guarda na variável 'payload' */
n2s(p, payload); 

/* 'pl' é o ponteiro que aponta para a palavra real que o cliente enviou */
pl = p; 

/* O servidor aloca memória cega baseada no tamanho que o cliente declarou! */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

/* A CÓPIA FATAL: Copia os dados da memória para o buffer de resposta */
memcpy(bp, pl, payload);
A função memcpy (Memory Copy) é impiedosa. Ela copia bytes do endereço de origem para o endereço de destino até atingir a quantidade solicitada. Ela não sabe onde uma palavra termina e onde a próxima começa.

3. O Ataque: O Sangramento da Memória Dinâmica (Heap)

Sabendo que o servidor não checa a verdade, o atacante forja um pacote Heartbeat mentiroso. Ele envia uma palavra muito pequena, mas declara no cabeçalho o tamanho máximo permitido pelo protocolo: 64 Kilobytes (65.535 bytes).

A Analogia do Ataque Heartbleed: * Atacante diz: "Servidor, repita a palavra 'B'. Ela tem 64.000 letras." * Servidor escuta: "Ok, vou alocar 64.000 espaços na minha memória de resposta." * Servidor processa: Ele lê a letra 'B' (1 byte). Faltam 63.999 bytes para cumprir a ordem. Como ele usa a função de cópia contínua, ele simplesmente varre a memória RAM adjacente ao pacote recebido, copiando tudo o que encontrar. * Servidor responde: "'B' + [63.999 letras de dados confidenciais que estavam armazenados na memória]".

O que havia nessa memória adjacente?

O Heartbeat processa as mensagens na memória Heap (memória alocada dinamicamente). É exatamente nesse mesmo local que o servidor armazena dados de outras conexões ativas. Ao "sangrar" esses 64KB extras, o servidor devolvia ao atacante:

  • Requisições HTTP de outros usuários.
  • Cookies de sessão (permitindo roubo de identidade).
  • Senhas em texto plano.
  • E, no pior cenário, a chave privada do certificado SSL do próprio servidor.

Como o atacante podia enviar pacotes Heartbeat várias vezes por segundo, ele podia "pescar" continuamente na memória do servidor até capturar dados valiosos.

4. A Correção

A solução para a vulnerabilidade, lançada na versão OpenSSL 1.0.1g, foi surpreendentemente simples. Bastou adicionar uma instrução condicional (if) para validar se o tamanho real dos dados enviados correspondia ao tamanho declarado no cabeçalho do pacote. 

/* Correção inserida no código: O Bounds Check */
if (1 + 2 + payload + 16 > s->s3->rrec.length) {
    return 0; /* Descarta o pacote silenciosamente se for uma mentira */
}

O Legado

O Heartbleed mudou a forma como a indústria da tecnologia enxerga projetos de código aberto. Ele evidenciou que infraestruturas críticas dependiam de bibliotecas mantidas por pouquíssimos voluntários e sem revisões de segurança adequadas, impulsionando a criação de iniciativas globais de auditoria de código que protegem a internet até hoje.