As linhas subsequentes cheias de bytes NUL são condensadas em uma única com um * a partir daí (como a ferramenta xxd).

Um exemplo em que memória mais "interessante" é vazada usando wget -O /dev/null https://google.com https://localhost:4433:

Como funciona?

Os heartbeats TLS podem ser enviados por qualquer um dos lados de uma conexão TLS. Após a conclusão do handshake, esses heartbeats são criptografados. Mas aparentemente o OpenSSL permite mensagens de heartbeat antes de o handshake ser concluído. Esses heartbeats (sobre a camada de registro) não são criptografados de forma alguma!

Isso torna muito fácil explorar a falha em clientes:

1. Aguarde um ClientHello contendo uma versão TLS e uma suíte de criptografia.
2. Envie um ServerHello contendo a mesma versão TLS e a mesma suíte de criptografia (para evitar falha no handshake).
3. Nesse ponto, o servidor pode enviar quantas requisições de heartbeat quiser.

Observe que não há necessidade de certificados, pois os heartbeats são aceitos antes de qualquer certificado ou chaves de criptografia serem trocados. Como o comprimento das requisições de heartbeat não é verificado, até 64 kiB de memória podem ser lidos da memória do cliente.

O pacemaker executa as etapas acima e considera um cliente como não vulnerável se a etapa 3 resultar em dados diferentes de Alertas. Se necessário para alguns protocolos (SMTP com STARTTLS, por exemplo), dados adicionais são trocados antes de o handshake TLS começar.

Uso avançado

Execute ./pacemaker.py -h para mais opções. As opções mais importantes são provavelmente -t (--timeout) e -x (--count). O timeout padrão é de 3 segundos, o que deve ser suficiente para a maioria dos clientes responderem (a menos que haja um link via satélite ou algo assim).

Exemplo para ser mais paciente por heartbeat (5 segundos) e obter quatro respostas de heartbeat:

Na teoria, os heartbeats agora podem levar vinte segundos, mas na prática você obterá respostas muito mais rápido.

Clientes testados

Os seguintes clientes foram testados com OpenSSL 1.0.1f no Arch Linux e vazaram memória antes do handshake:

• MariaDB 5.5.36
• wget 1.15 (vaza memória de conexões anteriores e do próprio estado)
• curl 7.36.0 (https, FTP/IMAP/POP3/SMTP com --ftp-ssl)
• git 1.9.1 (testado clone / push, vaza pouco)
• nginx 1.4.7 (em modo proxy, vaza memória de requisições anteriores)
• links 2.8 (vaza o conteúdo de visitas anteriores!)
• KDE 4.12.4 (kioclient, Dolphin, testado https e ftps com kde4-ftps-kio)
• Exim 4.82 (SMTP de saída)

O links é um ótimo exemplo que demonstra o efeito dessa falha em clientes. Ele é um navegador baseado em texto que vaza detalhes, incluindo cabeçalhos (cookies, tokens de autorização) e conteúdos de páginas.

Licença

O pacemaker é licenciado sob a licença MIT. Consulte o arquivo LICENSE para mais detalhes.

heartbleed.py

Esta é uma implementação que utiliza o pacemaker para criar pacotes. Ela tem a ressalva de que requisições repetidas precisam estabelecer uma nova conexão para cada tentativa, pois o servidor reinicia imediatamente a conexão após a primeira resposta de heartbeat.

A ressalva é uma limitação resultante da abordagem adotada; se o handshake também fosse concluído pelo cliente, muitos handshakes criptografados poderiam ser enviados sem falhas de conexão.

O heartbleed.py faz parte do pacemaker, portanto está sob os mesmos termos de licença.

Servidores testados

Os seguintes servidores foram testados com OpenSSL 1.0.1f no Arch Linux (salvo indicação em contrário):

• openssl s_server (HTTPS)
• nginx 1.4.7 (HTTPS)
• Dovecot 2.2.11 (IMAP / POP3)
• proftpd 1.3.4a-5+deb7u1 (FTP explícito)
• Exim 4.82 (SMTP)

ssltest.py

Este repositório também contém uma versão funcional que tem como alvo servidores. O ssltest.py foi criado por Jared Stafford ([email protected]), todos os créditos devidos são a ele! Foi obtido de http://s3.jspenguin.org/ssltest.py.

No momento, o script é compatível apenas com Python 2.