Do you have an affected version of openssl?
–
BraiamApr 7 '14 at 22:56

I've got the patched version 1.0.1-4ubuntu5.12 and I've restarted apache service but filippo.io/Heartbleed testing on my site still says I'm vulnerable Any idea why ?
–
user266576Apr 8 '14 at 8:32

1

@Mat I don't know what that site tests, but maybe it detects that you're using an old key. Since the key may have leaked, you need to regenerate it.
–
GillesApr 8 '14 at 10:09

1

You really don't want to update OpenSSL to wholesale new versions, that's an unbelievable pain. Far easier is to just install the updated package that patches the issue: ubuntu.com/usn/usn-2165-1
–
sarnoldApr 8 '14 at 17:09

have you restarted your services after upgrading?
–
AxelApr 14 '14 at 6:59

Not sure this works on Ubuntu 12.04.4 LTS. After full update, openssl version gives OpenSSL 1.0.1 14 Mar 2012. That’s not the patched version, right? Or am I misreading it?
–
Paul CantrellApr 8 '14 at 6:05

7

What to do with Ubuntu 13.04 ? No upgraded openssl available :-(
–
FrodikApr 8 '14 at 6:14

19

On Ubuntu 12.04 even the fixed OpenSSL displays version 1.0.1 14 Mar 2012. Read crimi's answer to find out whether your installation is including the fix.
–
danApr 8 '14 at 7:34

7

Thanks, @dan! Resummarizing @crimi's answer here: if you run dpkg -l | grep ' openssl ' and you get 1.0.1-4ubuntu5.12 then you’re good to go.
–
Paul CantrellApr 8 '14 at 8:21

Am I vulnerable?

Generally, you're affected if you run some server that you generated an SSL key for at some point. Most end-users are not (directly) affected; at least Firefox and Chrome don't use OpenSSL. SSH is not affected. The distribution of Ubuntu packages isn't affected (it relies on GPG signatures).

You are vulnerable if you run any kind of server that uses OpenSSL versions 1.0–1.0.1f. The affected Ubuntu versions are 11.10 oneiric through 14.04 trusty pre-releases. It's an implementation bug, not a flaw in the protocol, so only programs that use the OpenSSL library are affected. If you have a program linked against the old 0.9.x version of OpenSSL, it isn't affected. Only programs that use the OpenSSL library to implement the SSL protocol are affected; programs that use OpenSSL for other things are not affected.

If you ran a vulnerable server exposed to the Internet, consider it compromised unless your logs show no connection since the announcement on 2014-04-07. (This assumes that the vulnerability wasn't exploited before its announcement.) If your server was only exposed internally, whether you need to change the keys will depend on what other security measures are in place.

What is the impact?

The bug allows any client who can connect to your SSL server to retrieve about 64kB of memory from the server. The client doesn't need to be authenticated in any way. By repeating the attack, the client can dump different parts of the memory in successive attempts.

One of the critical pieces of data that the attacker may be able to retrieve is the server's SSL private key. With this data, the attacker can impersonate your server.

How do I recover on a server?

Take all affected servers offline. As long as they're running, they're potentially leaking critical data.

Upgrade the libssl1.0.0 package, and make sure that all affected servers are restarted.
You can check if affected processes are still running with `grep 'libssl.*(deleted)' /proc/*/maps

Generate new keys. This is necessary because the bug might have allowed an attacker to obtain the old private key. Follow the same procedure you used initially.

If you use certificates signed by a certification authority, submit your new public keys to your CA. When you get the new certificate, install it on your server.

If you use self-signed certificates, install it on your server.

Either way, move the old keys and certificates out of the way (but don't delete them, just ensure they aren't getting used any more).

Now that you have new uncompromised keys, you can bring your server back online.

Revoke the old certificates.

Damage assessment: any data that has been in the memory of a process serving SSL connections may potentially have been leaked. This can include user passwords and other confidential data. You need to evaluate what this data may have been.

If you're running a service that allows password authentication, then the passwords of users who connected since a little before the vulnerability was announced should be considered compromised. (A little before, because the password may have remained unused in memory for a while.) Check your logs and change the passwords of any affected user.

Also invalidate all session cookies, as they may have been compromised.

Client certificates are not compromised.

Any data that was exchanged since a little before the vulnerability may have remained in the memory of the server and so may have been leaked to an attacker.

If someone has recorded an old SSL connection and retrieved your server's keys, they can now decrypt their transcript. (Unless PFS was ensured — if you don't know, it wasn't.)

How do I recover on a client?

There are only few situations in which client applications are affected. The problem on the server side is that anyone can connect to a server and exploit the bug. In order to exploit a client, three conditions must be met:

The client program used a buggy version the OpenSSL library to implement the SSL protocol.

The client connected to a malicious server. (So for example, if you connected to an email provider, this isn't a concern.) This had to happen after the server owner became aware of the vulnerability, so presumably after 2014-04-07.

The client process had confidential data in memory that wasn't shared with the server. (So if you just ran wget to download a file, there was no data to leak.)

If you did that between 2014-04-07 evening UTC and upgrading your OpenSSL library, consider any data that was in the client process's memory to be compromised.

I don't believe "Only the server side of SSL/TLS connections is affected" is true. openssl.org/news/secadv_20140407.txt says it can reveal secrets from either client or server. ubuntu.com/usn/usn-2165-1 agrees. The chances that you are using client certificates while connecting to a malicious server are small, but the possibility exists.
–
armbApr 8 '14 at 12:14

@armb You make a good point. It doesn't even matter whether client certificates are used, the data leakage is unrelated to the use of certificates. I've enlisted the help of professionals.
–
GillesApr 8 '14 at 12:58

Client certificates are the case where you would leak private keys, but yes, passwords, authorization cookies etc. could leak anyway. However, with an OpenSSL based client like curl or wget in typical usage, you wouldn't have secrets for other sites in memory while connecting to a malicious server, so in that case I think the only leakage would be if you gave the client secrets anticipating giving them to a legitimate site, and Heartbleed leaked them during handshake before certificate verification reveals you aren't connected to the right site.
–
armbApr 9 '14 at 8:41

I've upgraded and get version 5.12 but this tool still tells me I'm vulnerable filippo.io/Heartbleed Thoughts?
–
toxaqApr 8 '14 at 11:23

3

I have tested our updated servers over this side and it told me that I'm not affected. Did you reboot your system, or at least are you sure that all necessary processes have been restarted?
–
crimiApr 8 '14 at 11:33

3

After updating the OPENSSL, all I had to do was to restart the apache service, but graceful did not helped. I had to go and restart by using sudo service apache2 restart
–
Tom HertApr 8 '14 at 17:14

1

I just found the cause of my vulnerability: i had mod-spdy-beta installed. After removing it and restarting apache all tests are green now.
–
Andreas RothApr 9 '14 at 5:30

3

Updating openssl doesn't fix applications such as Apache, Nginx or postfix. You have to update libssl1.0.0 and restart them as explained in other posts.
–
tnjApr 10 '14 at 10:28

Heh, now that I take the time to read the details of this posting, I'm even more aghast -- downloading a tarball from some random place off the Internet, unpacking, and executing parts of it as root is just reckless behaviour. It'd be slightly better if the tarball signatures were downloaded and checked, but making sure you validate the signatures were signed by the right key is itself a difficult question. Distributions have already gone to the effort to ensuring safe provenance of tarballs and patches. Thanks.
–
sarnoldApr 9 '14 at 0:05

For those who do not want to do a serverwide package upgrade. I read a bunch of these guides today and apt-get upgrade openssl === apt-get upgrade this will apply all security fixes required by your machine. Wonderful, unless you are explicitly leaning on an old package version somewhere.

This is the minimal action required on Ubuntu 12.04 LTS running Apache 2:

Go to this address and prove you have the vulnerability. You should use the DIRECT EXTERNAL ADDRESS OF YOUR WEB SERVER. If you use a loadbalancer (for example ELB) you might not be contacting your web server directly.

Run the following 1 liner to upgrade packages and restart. Yes I saw all the guides saying that you should have a timestamp later than April 4th 2014, this doesn't seem to be the case to me.

Using an external site to prove a vulnerability in a server seems to be the wrong approach to me.
–
RinzwindApr 8 '14 at 22:00

External vulnerability testing scripts are becoming more and more commonplace these days. It does exactly what an internal script does, the connection is just initiated from an external webserver. You can look to sites like WhiteHatSecurity.com for an example of a program that initiates all connections remotely. There are instances where this wouldn't fly, for example network vulnerability testing but for testing a forward facing webserver (which in general an SSL server will be) this is almost ideal.
–
AdrianApr 8 '14 at 23:03

"External vulnerability testing scripts are becoming more and more commonplace these days. " that opens the possibility of that external site abusing my system: all they need to know it fails and hack my system before I patch it. No this is not the correct way. (and yes I host my own sites with apache and openssl).
–
RinzwindApr 10 '14 at 12:13