Many, many corporate websites, of companies of all sizes, have been (or
still need to be!) patched to fix the Heartbleed vulnerability.

The vulnerability has existed since December 31, 2011, with OpenSSL
being used by about 66% of Internet hosts.

As a user, chances are that sites you frequent regularly are affected and that your data may have been compromised. As a developer or sys admin, sites or servers you’re responsible for are likely to have been affected as well.

So what do I need to do to protect myself if I use any of the affected sites?

The main thing you should do immediately is to change your passwords for
any of the affected sites for which you have a login account.

And what do I need to do to fix and protect against Heartbleed if I’m the sys admin for a site that uses OpenSSL?

If you’re using OpenSSL 1.0.1, do one of the following immediately:

Upgrade to OpenSSL 1.0.1g, or

Recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

If you’re using OpenSSL 1.0.2, the vulnerability will be fixed in
1.0.2-beta2 but you can’t wait for that. In the interim, do one of the
following immediately:

Revert to OpenSSL 1.0.1g, or

Recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

Most distributions (e.g., Ubuntu, Fedora, Debian, Arch Linux) have upgraded their packages already. In cases like Gentoo, you can upgrade to a patched ebuild.

Once you’ve upgraded (or recompiled) and have established a secure
version on your server:

Be sure to restart all potentially affected processes. Major daemons affected by the bug include Apache, Nginx, OpenVPN, and sshd; basically anything and everything linked against libssl. (Note that a restart of these daemons should be sufficient. There should be no need to rebuild these binaries since they are dynamically linked with the openssl libraries.)

If your infrastructure was vulnerable, there are Heartbleed tutorial steps that you can and
should take. A useful list of such mitigations is available here.

More gory Heartbleed details, for those who are interested…

As explained in the GitHub commit for the
fix,
a missing bounds check in the handling of the TLS heartbeat extension could be exploited to reveal up to 64k of memory to a connected client or server.

While the exposed memory could potentially just be garbage, it could
just as easily turn out to be extremely valuable to a malicious
attacker.

Here’s how the Heartbleed vulnerability works: An attacker provides the payload as
well as the payload length. However, no validation is done to confirm
that the payload length was actually provided by the attacker. If the
payload length was not provided, an out-of-bounds read occurs, which in
turn leaks process memory from the heap.

Leaking previous request headers can be a very serious security problem. Specifically, a prior user’s login post data might still be available with their username, password, and cookies, all of which can then be exposed and exploited. Moreover, although private key leakage through Heartbleed was initially deemed to be unlikely, it has been verified that private SSL keys can be stolen by exploiting this vulnerability.

The vulnerability is also made possible due to OpenSSL’s silly use of a malloc() cache. By wrapping away libc functions and not actually
freeing memory, the exploitation countermeasures in libc are never given
the chance to kick in and render the bug useless.

Additional details on these ways to fix Heartbleed are available here and here.

Kudos to the discoverer, Neel Mehta of Google Security, as well as Adam
Langley and Bodo Moeller who promptly provided the patch and helped sys admins determine how to fix Heartbleed. I also encourage you to educate yourself on some of the other common web security vulnerabilities to avoid issues in the future.

About the author

With a background in IT-Security, Gergely has worked as lead developer for an Alexa Top 50 website serving several million unique visitors each month. He is a diligent and motivated worker who likes to dive in and get things done. [click to continue...]

Comments

Robert Lujo

According to the answer on StackOverflow http://utrust.rlujo.co/heartbleed-and-openssh SSHD is not affected: "OpenSSH uses OpenSSL, but not to implement the SSL protocol. It's used for other things. The SSH protocol is not built on top of SSL; it's somewhat similar, but not identical, and in particular does not include the feature that's buggy. Only programs that use OpenSSL's implementation of the SSL protocol are at risk."

Robert Lujo

What is also interesting is that if you run a client that uses vulnerable implementation of SSL protocol, a server can read client's memory, i.e. http://heartbleed.com/: "you might have client side software on your computer that could expose the data from your computer if you connect to compromised services.", and http://unix.stackexchange.com/a/123712/64724 "The bug also allows any server that your SSL client connected to to retrieve about 64kB of memory from the client at a time.".

daneroo

Thanks for the summary. That XKCD link is the best laymans overview I have seen so far!

Gergely Kalman

I can confirm this, having played with the SSH protocol in the past.

Rodrigo Alves

Months after the incident this is the best introductory article on the matter. Very succinct and well referenced. Thanks!

Rolland Smith

Hey Guys!!! I got mine from Anna. My blank ATM card can withdraw €2,000 daily. I got it from Her last week Wednesday and now I have €7,000 for free. The card withdraws money from any ATM machines and there is no name on it, it is not traceable and now i have money for bussiness and enough money for me and my 4 kids. I am really happy i met Anna because i met two people before him and they took my money not knowing that they were scams. But am happy now.Anna sent the card through DHL and i got it in two days. Get one from her now. She is giving it out to help people even if it is illegal but it helps a lot and no one ever gets caught. The card works in all countries except Philippines, Mali and Nigeria. Anna's email address is annaroddy174@gmail.com

With a background in IT-Security, Gergely has worked as lead developer for an Alexa Top 50 website serving several million unique visitors each month. He is a diligent and motivated worker who likes to dive in and get things done.