OpenSSL “Heartbleed” bug undermines widely used encryption scheme

OpenSSL, an open-source cryptographic library that is the default encryption engine for popular Web server software and is used in many popular operating system and apps, sports a critical vulnerability that can easily be misused by attackers to impersonate online services and steal information users believe to be protected by SSL/TLS.

What’s even worse is that such an attack leaves no physical trace in the logs, so it’s impossible to tell whether the vulnerability – dubbed the “Heartbleed Bug” by the Codenomicon and Google researchers who identified it – has been exploited in the wild since it was first introduced in December 2011.

“A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server,” OpenSSL explained in a short advisory.

“There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed,” the researchers behind the discovery explained further.

“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content.”

They pointed out that the flaw is not in the SSL/TLS protocol itself, but is a programming mistake in the OpenSSL library that provides cryptographic services such as SSL/TLS to the applications and services.

The impact of the flaw could be huge. “Most notable software using OpenSSL are the open source web servers like Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% according to Netcraft’s April 2014 Web Server Survey,” they pointed out.

“Furthermore OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software. Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most. Furthermore OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates.”

OpenSSL 1.0.1 through 1.0.1f are vulnerable. OpenSSL 1.0.1g, which was released on Monday, is not, as well as the OpenSSL 1.0.0 and 0.9.8 branches.

“Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users,” the researchers explained the next move. “Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.”

“Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption,” they explained. “All this has to be done by the owners of the services.”

Here is a short to-do list for checking whether one’s installations are vulnerable and fix the problem if there is one, and SANS ISC’s Johannes Ullrich warns to do it fast, as a proof of concept exploit for remotely scanning for vulnerable systems has been made available.

“It is essential that all affected systems get updated immediately. Also, to mitigate attacks resulting from any potentially leaked keying material, any SSL keys from affected systems should be replaced and revoked. Depending on the service / protocol, one needs to think about other potentially leaked data and take appropriate action,” commented Mark Schloesser, Security Researcher at Rapid7.

“The leaked memory areas might contain a lot of different contents ranging from leftover data from previous communication over log messages up to private key material employed by the service / daemon. For this reason, there are lots of possible attack scenarios that can result from the vulnerability,” he explained. “An attacker who gains access to the private key of the server certificate can subsequently mount man-in-the-middle attacks against clients and impersonate the server/service. Log messages might also contain credentials or affect the privacy of communications by other clients.”