(this article is work in progress and will be updated as we have new information. Also see the comments for links to signatures and other information provided by readers)

We decided to go to Infocon Yellow to alert readers of this vulenrability.

For those of you using OpenSSL 1.0.1 (most recent Unix systems), it is critical that you patch the openssl library, as well as binaries compiled statically with openssl, as soon as possible. [1]

The attack will allow a remote attacker to read up to 64kBytes of system memory from your system per attack attempt. The attack works against servers as well as against clients. While not all software using SSL necessarily uses the OpenSSL library, many do. (see our prior diary)

A proof of concept exploit has been made available and I have tested it. It can be used to remotely scan for vulnerable systems. [1] We have not yet detected wide spread use of the exploit, but it is literally hours old. At this point, we don't think the vulnerability was known in the underground before the official release, but it is possible.

What should you do first:

Check if you are vulnerable. "openssl version -a" will return the version information. If your version is 1.0.1, you MAY be vulnerable. Only version 1.0.1g is NOT vulnerable. Other major versions (0.9x, 1.0.0 ...) are not vulnerable.

Rule of thumb: If you are using OpenSSL, and if you are supporting TLS 1.2 (check ssllabs.com) , then you are vulnerable unless patched.

If I am vulnerable, what should I do:

Patch! Ubuntu, CentOS and others have patches available. OS X Mavericks has NO PATCH available. Windows is likely not vulnerable, but if you are running open source software like Apache that uses OpenSSL, then you may be vulnerable.

You may want to consider replacing SSL certificates if you are afraid that the exploit was already used against your site. But the exploit is not limited to secret SSL key. All data in memory is potentially at risk.

Can I test remotely?

The PoC exploit above can be used to scan your network remotely.

How Can I Tell if Someone is Using the Exploit Against Me

We don't have IDS signatures (yet... wait for updates here). There is no log entry in your web server log as the exploit happens after the SSL session is established, and before the HTTP request is sent.

Go over to https://www.ssllabs.com/ssltest/index.html and enter your SSL site URL. If you know your system uses Linux and you see TLSv1.2 enabled, you're vulnerable unless you've already patched or somehow are not running OpenSSL on Linux.

If TLS 1.0 is the latest version, you may not be vulnerable because the older v0.9.8 did not support TLS 1.1 and TLS 1.2. Or it could just be disabled but still vulnerable.

If you have so-called "appliances" you're probably running some Linux and OpenSSL variant.

Regarding Mac OS X Mavericks, I did a check on my system and saw that the version is 0.9.8y, this may be why there is no patch available. So, at least it's not vulnerable to Heartbeat, but I'm sure that it is vulnerable to other things. I'm not serving anything up from my system, so this is more of an FYI.

So what about the period of time systems have been vulnerable? Folks are asking whether they need to change passwords. Patching, in this case, is the easy part. Is there any obligation to get your users to change their passwords once systems are patched and certificates replaced given that no one really knows whether their site was compromised or not?

Great as the ssl labs tool is for testing web server vulnerability to heartbleed, does anybody know of a way to test a mail server implementation of SSL? Like imap.gmail.com or smtp.gmail.com? As ssl labs seems to be unable to fingerprint the SSL service running on these servers.

We need to know the answer to this question about changing passwords that have been transmitted across the internet from PCs and Apple devices. Please email me when you have clear instructions on: 1 - is it necessary? 2- any "gotcha's" to be aware of in resetting passwords? 3 - what can non-Linux users do to protect against future similar situations (besides cut Internet connection and go live on a farm)? Thank you, jbrande2@uncc.edu and jim.branden.pmp@gmail.com