As a matter of fact, yes, clients are vulnerable. So far the attention has been focused on servers as they are much more open to exploitation. (Almost) everyone can connect to a public HTTP/SMTP/... server.
This blog describes how the bug actually works (it mentions dtls_process_heartbeat()
, but tls_process_heartbeat()
is affected in the same way). This function is used both for clients and server applications, so indeed clients should be vulnerable too.
According to RFC 6520, heartbeats should not be sent during handshakes. In practice, OpenSSL accepts heart beats right after the sending a ServerHello (this is what Jared Stafford's ssltest.py does). Upon further testing, I have discovered that servers can abuse clients by sending a Heartbeat right after sending the ServerHello too. It triggers the same bug.
A proof of concept can be found in my repo at https://github.com/Lekensteyn/pacemaker. From its README:
The following clients have been tested against 1.0.1f and leaked
memory before the handshake:
- MariaDB 5.5.36
- wget 1.15 (leaks memory of earlier connections and own state)
- curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
- git 1.9.1 (tested clone / push, leaks not much)
- nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
- links 2.8 (leaks contents of previous visits!)
- KDE 4.12.4 (kioclient, Dolphin, tested https and ftps with kde4-ftps-kio)
- Exim 4.82 (outgoing SMTP)
It has been demonstrated that 64 KiB of memory (65535 bytes) can indeed returned. It has also been demonstrated that clients (wget
, KDE Dolphin, ...) can leak data like previous requests possibly containing passwords.