This afternoon, many of the net security people I know are freaking out. A very serious bug in OpenSSL — a cryptographic library that is used to secure a very, very large percentage of the Internet’s traffic — has just been discovered and publicly disclosed.

Even if you’ve never heard of OpenSSL, it’s probably a part of your life in one way or another — or, more likely, in many ways. The apps you use, the sites you visit; if they encrypt the data they send back and forth, there’s a good chance they use OpenSSL to do it. The Apache web server that powers something like 50% of the Internet’s web sites, for example, utilizes OpenSSL.

Through a bug that security researchers have dubbed “Heartbleed“, it seems that it’s possible to trick almost any system running any version of OpenSSL from the past 2 years into revealing chunks of data sitting in its system memory.

Why that’s bad: very, very sensitive data often sits in a server’s system memory, including the keys it uses to encrypt and decrypt communication (read: usernames, passwords, credit cards, etc.) This means an attacker could quite feasibly get a server to spit out its secret keys, allowing them to read to any communication that they intercept like it wasn’t encrypted it all. Armed with those keys, an attacker could also impersonate an otherwise secure site/server in a way that would fool many of your browser’s built-in security checks.

And if an attacker was just gobbling up mountains of encrypted data from a server in hopes of cracking it at some point? They may very well now have the keys to decrypt it, depending on how the server they’re attacking was configured (like whether or not it’s set up to utilize Perfect Forward Secrecy.)

The exploit relies on a bug in the implementation of OpenSSL’s “heartbeat” feature, hence the “Heartbleed” name. Security firm Codenomicon has written an in-depth breakdown of the Heartbleed bug here.

To quote their findings:

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.
It seems the bug has been in OpenSSL for 2+ years (since December 2011, OpenSSL versions 1.0.1 through 1.0.1f) before its publicly announced discovery today. Even worse, it appears that exploiting this bug leaves no trace in the server’s logs. So there’s no easy way for a system administrator to know if their servers have been compromised; they just have to assume that they have been.

The bug was discovered and reported to the OpenSSL team by Neel Mehta of Google’s security team. OpenSSL released an emergency patch for the bug along with a Security Advisory this afternoon.

OpenSSL Security Advisory (07 Apr 2014)
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

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.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

Yes, clients are vulnerable to attack.

A malicious server can use the Heartbleed vulnerability to compromise an affected client. Sources below (all emphasis below is mine).

heartbleed.com :
Ubuntu Security Notice USN-2165-1 :
RFC6520 :
OpenSSL Security Advisory 07 Apr 2014 :
Information on common clients:

• Windows (all versions): Probably unaffected (uses SChannel/SSPI), but attention should be paid to the TLS implementations in individual applications. For example, Cygwin users should update their OpenSSL packages.
• OSX and iOS (all versions): Probably unaffected. SANS implies it may be vulnerable by saying "OS X Mavericks has NO PATCH available", but others note that OSX 10.9 ships with OpenSSL 0.9.8y, which is not affected. Apple says : "OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS"
• Chrome (all platforms except Android): Probably unaffected (uses NSS)
• Chrome on Android: 4.1.1 may be affected (uses OpenSSL). 4.1.2 should be unaffected, as it is compiled with heartbeats disabled.
• Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey, Fennec): Probably unaffected, all use NSS

OpenSSL

Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged. If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API. Common Crypto and Security Transforms are the recommended alternatives for general encryption. CFNetwork and Secure Transport are the recommended alternatives for secure communications.

Es ist sicherlich nicht verkehrt, jetzt mal ein paar wichtige Passwörter von Online-Diensten auszutauschen. Wer weiß, wer die Informationen in den letzten zwei Jahren schon abgegriffen hat ...