Discovery of a memory leak bug in OpenSSL means that each and every internet user is likely to have been affected either directly or indirectly.
Dubbed the “Heartbleed Bug”, this vulnerability allows stealing of information that usually would be encrypted by a secure SSL/TLS session over the internet.
Everyday Bitcoin client operation does not directly use OpenSSL, however, the Bitcoin Core 0.9.0 (and each prior version) uses OpenSSL for remote procedure calls (RPC) via https. New functionality introduced in version 0.9.0 is the ability to fetch payment requests via https and this feature is, therefore, currently insecure. Whilst the Bitcoin Core client will be updated to 0.9.1 to address the OpenSSL vulnerability, the core developers stress that the Bitcoin protocol itself is not affected by the Heartbleed bug.
Widespread Vulnerability
SSL/TLS encryption provides secure and private communication between users and web-based services such as websites, email, instant messaging (IM), and virtual private networks (VPNs), including Tor .
The Heartbleed Bug (CVE-2014-0160 ) allows anyone snooping on a connection protected by vulnerable OpenSSL versions, to obtain leaked session keys and to, therefore, eavesdrop on communications, obtain data (including usernames and passwords) and to impersonate users and services.
The bug (in OpenSSL 1.0.1) was first introduced in March 2012 and has been out in the wild for two years until it was discovered and fixed on 7 April 2014.
Why “Heartbleed”?
OpenSSL’s transport layer security protocol implements a heartbeat between the client and server ends of the connection. The exploitation of this heartbeat causes memory leaks to be transmitted bi-directionally and in-the-clear between client and server.
Is This An SSL/TLS Design Flaw?
No. It was merely an implementation problem (programming mistake) in OpenSSL versions since 1.0.1. Prior versions did not feature the Heartbleed bug.
What Is Being Leaked?
Armed only with the intent to eavesdrop and some basic unprivileged tools an attacker can obtain secret keys used for the core X.509 certificates used by OpenSSL, and then proceed to obtain:
- user names and passwords,
- instant messages,
- emails and
- most of the sensitive data that one would routinely access via “logging-in” to online sites and services.
Am I Affected?
If you use the internet, then the answer is “yes”. OpenSSL is the most popular cryptographic library used to encrypt traffic over the web.
A recent survey reveals that open source web servers, Apache and Nginx, run 66% of websites out on the web. By default, they use OpenSSL.
The widespread use of postfix and other open-source email servers also means that supposedly secure SMTP, POP and IMAP connections have been vulnerable – all those emails being sent and received, over a period of 2 years.
OpenVPN, arguably the most popular VPN solution being offered by vendors, uses OpenSSL to secure and encrypt private WAN connections.
Tor, the darling of the Dark Web, uses OpenSSL to pass encrypted traffic securely between relays. Conceivably, with the IP addresses of most Tor relays being public knowledge, the Tor traffic of the past two years has been under a microscope, instead of the cloak that anonymous surfers assumed.
What versions of the OpenSSL are affected?
Status of different versions:
- OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
- OpenSSL 1.0.1g is NOT vulnerable
- OpenSSL 1.0.0 branch is NOT vulnerable
- OpenSSL 0.9.8 branch is NOT vulnerable
Vulnerable Operating Systems
Some open-source operating system distributions that have shipped with potentially vulnerable OpenSSL version:
- Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
- Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
- CentOS 6.5, OpenSSL 1.0.1e-15
- Fedora 18, OpenSSL 1.0.1e-4
- OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
- FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c)
- NetBSD 5.0.2 (OpenSSL 1.0.1e)
- OpenSUSE 12.2 (OpenSSL 1.0.1c)
What can I do?
- Users
- Upgrade to the latest fixed OpenSSL version 1.0.1g or newer.
- Start a systematic project to improve your password methodology and update all passwords to your new improved standard.
- Administrators
- For every vulnerable SSL service you manage:
- Upgrade the OpenSSL version to 1.0.1g
- Regenerate your private key
- Request and replace the SSL certificate
If an upgraded package is not yet available for your OS, software developers can recompile OpenSSL with the handshake removed from the code by a compile-time option
-DOPENSSL_NO_HEARTBEATS
Consider all usernames a password used over the past two years as compromised. Whilst, not all SSL encrypted sites (https) use OpenSSL, it is difficult for the end-user to determine the exact version. Additionally, an attacker or eavesdropper leaves no known trace of their activity.
If you’re a Bitcoin Core user and you have enabled RPC via SSL, you need to upgrade to at least OpenSSL 1.0.1g and recreate your SSL server key and certificate. Users who wish to fetch payment requests via SSL should refrain from using this service until the updated core 0.9.1 has become widely adopted.
Tests for Vulnerability
Test your vulnerability by requesting a large heartbeat response. If the server replies accordingly, your SSL service is most likely vulnerable. Use one of the tests below:
- https://filippo.io/Heartbleed/ : a web-based test
- https://s3.jspenguin.org/ssltest.py : a python script to test for the vulnerability from the command line
