Table of Contents
Ubuntu - Vulnerabilities - HeartBleed
Heartbleed was introduced in OpenSSL version 1.0.1 and is patched with OpenSSL version 1.0.1g. Details are in CVE-2014-0160.
The bug allows any attacker to read the memory of a vulnerable host, which means that any keys that have been used on a host with a vulnerable version of OpenSSL should be considered compromised.
Distributions have been updating their packages and pushing out updates, but users need to pull down the most recent packages and revoke any previous keys based on insecure versions.
Checking the OpenSSL Version Numbers
sudo dpkg -l | grep "openssl"
returns:
ii openssl 1.0.1e-2+deb7u6 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools
To Fix
sudo apt-get update sudo apt-get dist-upgrade
If you only want to upgrade the affected packages, and not update the entire system (only recommended if you have reason to believe that upgrades to other components will break your system), you can selectively upgrade the OpenSSL packages by typing:
sudo apt-get install --only-upgrade openssl sudo apt-get install --only-upgrade libssl1.0.0
Revoking and Reissuing Your SSL Certs/Keys
If you have purchased an SSL certificate from a provider and you have updated your OpenSSL packages on your server, you will need to revoke your old keys and you'll have to reissue new keys. This is a process known as “rekeying”.
You can generate your new SSL CSR by typing something like this.
openssl req -new -newkey rsa:2048 -nodes -keyout hostname.key -out hostname.csr
You will need to copy your generated CSR into your provider's web interface after generation in order to rekey your server. You will then need to download the new certificate from the web interface.
You will have to install the new keys to the same location that your old keys and certificates were kept. The path that you'll need to use for your certificate and keys will vary by distribution and how you configured your web server. For instance, some are kept in /etc/ssl/certs while others may be kept in locations provided by your web server.
For example, if you are using the Apache web server, you should see a line in your main Apache configuration file, a virtualhost file, or a separately sourced configuration file that points to the location where it looks for your SSL information:
SSLEngine on SSLCertificateFile /path/to/your_domain.crt SSLCertificateKeyFile /path/to/your_key.key SSLCertificateChainFile /path/to/CA.crt
These may look different, but they should point you in the correct direction to find your SSL certificate location.
If you are using Nginx, you'll find similar directives that point to your server's SSL certificate and key. They might look something like this:
server { . . . ssl_certificate /path/to/your_domain.crt; ssl_certificate_key /path/to/your_key.key; . . . }
Restart your web server by typing:
sudo service apache2 restart # For Apache web server sudo service nginx restart # For Nginx web server
Additional Considerations from a Client's Perspective
You should consider any communication that you secured by SSL previously to have been compromised by this bug. This means any kind of interaction with secure websites were open to snooping.
A good first step is to change your password on every site that you use, after you have verified that they have updated their OpenSSL versions to patch this vulnerability. If you change your password prior to the remote site patching their SSL version, your new password is just as vulnerable as your old one.
One consideration that is of high importance is to secure any VPN instances that you have set up. There are a few different ways that VPN connections are implemented, but SSL is one of the most popular. For instance, OpenVPN uses SSL. Any certificates required to connect to your server should be regenerated to ensure that they are secured.
Another good measure is to remove all session keys and cookies. This means regenerate API keys, clear cookies that are stored in your browser, etc. This may be a massive inconvenience, but the cost of not going through these pains now is that your accounts are basically wide open and communication with remote servers that have not updated their OpenSSL should be considered no more secure than plain-text.