2014-04 Heartbleed Bug
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by SSL/TLS encryption.
OpenSSL versions from 1.0.1 through 1.0.1f (inclusive) are vulnerable and make it possible to steal information, including the encrypted content and the secret key used for the encryption. The attack is also undetectable.
If you are running any of the affected versions on an SSL-enabled website, meaning that you can access it using HTTPS instead of HTTP, patch the libraries in your system and replace the certificates and keys that may have been compromised. Please notice that remote access using SSH is NOT affected.
Detect if your machine is vulnerable
If you are running a Web server with SSL enabled, test whether it is vulnerable using this website.
Alternatively, log into the server and check the OpenSSL version by executing the command below:
$ openssl version -a
If the version in the output is greater or equal to v1.0.1 and lower than or equal to v1.0.1f, you may be affected. An example of an affected version would be:
$ openssl version -a OpenSSL 1.0.1 14 Mar 2012 built on: Wed Jan 8 20:45:51 UTC 2014 platform: debian-amd64
An example of a secure version would be:
$ openssl version -a OpenSSL 1.0.1g 7 Apr 2014 built on: Tue Apr 8 09:07:07 CEST 2014 platform: linux-x86_64
In this example, the OpenSSL version is greater than v1.0.1f and so it may be considered secure. This is the output you will see if you use our patch installer to update your SSL version (described in the next section)
Another detail to check is the “built on” date. Some Linux distributions have provided security patches that fix the vulnerability without upgrading OpenSSL. The “built on” date should be newer or equal to April 2014 to consider it secure. An example of a patched OpenSSL version would be:
$ /usr/bin/openssl version -a OpenSSL 1.0.1 14 Mar 2012 built on: Mon Apr 7 20:33:29 UTC 2014 platform: debian-amd64
In this example, the OpenSSL version is in the vulnerable range but it may be considered secure as it was patched in April 2014.
Secure your machine
Follow the steps below:
Patch the library located in the /opt/bitnami directory, by downloading and installing an update for your platform.
For Ubuntu Linux 12.04 LTS 64-bit systems:
$ wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run
For Ubuntu Linux 12.04 LTS 32-bit systems:
$ wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1g-1-linux-installer.run
Install the patch using the commands below:
$ chmod +x ./bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run $ sudo ./bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run
The patch will check if your installation is vulnerable and if so, update the library version to a safe one. At the end of the patching process, it will ask for permissions to restart your services (recommended) so the changes take effect. It will also save all the updated files in the /opt/bitnami/opensslfix directory and the replaced files (in case they are needed to perform a rollback) in the /opt/bitnami/opensslfix/backup/ directory.
Update the system OpenSSL library:
$ sudo apt-get update $ sudo apt-get install -y libssl1.0.0 openssl
Check that the library was updated:
$ /usr/bin/openssl version -a OpenSSL 1.0.1 14 Mar 2012 built on: Mon Apr 7 20:33:29 UTC 2014
Restart any service using libssl. To find the list of those services, use the command below:
$ sudo lsof -n | grep ssl | grep DEL vsftpd 479 root DEL REG 202,1 394910 /lib/x86_64-linux-gnu/libssl.so.1.0.0 monit 1254 root DEL REG 202,1 394910 /lib/x86_64-linux-gnu/libssl.so.1.0.0
Then, restart the services. Using the example above, here are sample commands:
$ sudo /etc/init.d/monit restart $ sudo /etc/init.d/vsftpd restart
After applying the patches above, double-check if your website is still vulnerable using this website.
The vulnerability allows an attacker to steal private keys, which would allow it to decrypt any information, as well as impersonating your server. It is advisable to revoke potentially-compromised keys and reissue and redistribute new ones. This is only necessary if you configured HTTPS using your own certificate. In this case, regenerate new certificates and configure them again in your server.
Please direct any questions you have about this issue on our github repository.