Heartbleed

Heartbleed is a vulnerability that affects the OpenSSL library in all its 1.0.1 versions, up to 1.0.1f. It was made public April 7 and assigned CVE-2014-0160. The vulnerability is due to a missing bounds check in the code handling TLS heartbeat extension packets. An attacker could leverage the bug by sending a heartbeat request with a specified length and a payload much smaller, being able to retrieve up to 64KB of memory from the server. The OpenSSL project released version 1.0.1g right after the vulnerability was public to address the bug. Major vendors issued updated packages with the library fixing the problem, making it possible to stop the leakage of data from servers.

Despite the small amount of data being leaked, the vulnerability is specially dangerous because it leaves absolutely no trace in the log files, and therefore an attacker can use it repeatedly to obtain data from different parts of the memory of the server. The bug was supposed to be able to leak critical information such as the private key used by servers when establishing TLS protected connections with browsers, although some voices claimed that such goal would be very difficult if not impossible to achieve. Several researchers and security specialists confirmed that it is possible to obtain the private key, however. This makes this vulnerability really dangerous and critical, as there are now many exploits available online that make it trivial to obtain private information from compromised servers.

The vulnerability has gone world wide due to its high impact on web servers across the Internet. It is believed that it affects around 17% of the total amount of web servers in the Internet, which is a non-negligible amount. Many services and sites like Google, Yahoo, Instagram or Tumblr were affected. However, the vulnerability affects not only web servers, but also any other online service making use of the OpenSSL library to establish a TLS connection. That includes SMTP, LDAP, IMAP, POP3, FTP or OpenVPN, among others. Even IP-telephones and mobile telephones are affected.

In the web context, it affects two major web server packages that use OpenSSL: Apache and nginx. If any of those servers are using a vulnerable version of OpenSSL, they will be vulnerable and leak sensitive data, such as session cookies or user credentials. It doesn’t matter how they are configured, as any data available in the execution context where a TLS connection is established (that is, the HTTP request received from the client) will be in memory and therefore available to attackers. On the other hand, when executing user applications such as PHP scripts, their secrets might be safe depending on how the server was configured. If, for example, Apache is configured in CGI or FastCGI mode to execute PHP, the latter will be executed in a different process, and therefore its sensitive data is not available through heartbleed exploitation. On the contrary, when using mod_php, the execution context of a PHP script is fully exposed.

How is SimpleSAMLphp affected?

In what relates to SimpleSAMLphp, the same principles apply. Even though SimpleSAMLphp itself uses OpenSSL, it uses it for purposes completely unrelated to the heartbleed vulnerability, and therefore it is not directly affected. Those using SimpleSAMLphp in a web server that is not affected by the vulnerability, can rest assured that they won’t be affected because of SimpleSAMLphp. However, SimpleSAMLphp can be affected by the vulnerability depending on its execution context. If PHP is run in the same process handling a vulnerable TLS connection (that is, mod_php), then SimpleSAMLphp is exposed together with all its secrets and sensitive data.

We have evaluated the impact of the heartbleed vulnerability on a SimpleSAMLphp installation, and we concluded that anything in its code, configuration or execution context can be accessible to an attacker, and therefore must be considered compromised. Here is a (non extensive) list of data that may be compromised by leveraging the vulnerability:

• Session information (i.e. cookies used to keep track of a user).
• User credentials (usernames and passwords, regardless of the backend used).
• Administrator password.
• Signature and encryption keys.
• Secret salt.
• Cron module key.

How should I proceed?

We recommend all SimpleSAMLphp users running Apache or nginx to perform the following steps to assess if they are vulnerable, and in such case, restore their installation to a secure state.

1. Check if your web server is vulnerable. If not, you are done.

2. If your web server is vulnerable, you will need first to update your version of OpenSSL to one which is not vulnerable. OpenSSL version 1.0.1g is no longer vulnerable, but other vendors may have issued patched packages of prior versions. Please refer to your operating system documentation for detailed instructions on how to update the packages, and make sure you install one with the vulnerability solved. After updating, go back to step 1 and verify that your site is no longer vulnerable.

3. Now that attackers cannot leverage the vulnerability to get sensitive information from your server, you need to issue a new certificate for your web server. Make sure to use a new private key, as the old one might be compromised. Once you have a new certificate in place (probably signed by a third party), you need to revoke the old one. This is specially important as if you don’t revoke the old certificate and an attacker got your private key, he would be able to impersonate your web server and trick users to visit his own fake server, with the user’s browser not being able to tell the difference. Make sure you reload your servers using the new certificate so that they start using it instead of the old one.

4. Now you need to assess if SimpleSAMLphp was compromised. If you are running PHP in CGI mode, then you shouldn’t be affected and therefore you can skip all steps related to SimpleSAMLphp. If not, you must assume your installation to be compromised.

5. If your SimpleSAMLphp was compromised, then you need to change a few things. First, change your administrator password. We recommend you to use a SSHA password instead of a plaintext one, as in this case the attacker would need to break the hash to know the real password. If your password is secure enough (long, not a word in the dictionary, with a reasonable mix of characters, numbers and symbols), then it will be pretty difficult to obtain the original password, and therefore your new password will be more secure if your installation gets compromised again. You can change the administrator password with the auth.adminpassword option in the config/config.php file.

6. If you are using the cron module, change the corresponding key.

7. You may want to evaluate if you want to change the secret salt. Changing it may affect the generation of some of the attributes issued by an identity provider, and therefore that would change authentication (and maybe authorization) in service providers. Therefore, you need to balance how critical it is that your salt is known (what is the danger?) and the practical problems you will have if you change it. For large production systems that rely somehow in attributes like eduPersonTargetedId, it might be a bad idea to change it, but you need to assess your specific case.

8. Change any other sensitive information that might be stored in your configuration, like MySQL or LDAP passwords. Anything that was in your configuration files might have been stolen and therefore is compromised.

9. Invalidate all the existing sessions. Depending on your session backend, you can do that in different ways. The principle is that you need to remove all the sessions from your backend. If the time passed between the moment when you updated your server and now is greater than your session timeout, all the sessions that might have been hijacked are now expired, and you don’t need to take action.

10. Your SAML signature and encryption keys might have been compromised too. Therefore, you need to change them. Refer to the documentation for more information on how to perform a key rollover. You need to understand that if you don’t perform a key rollover, you can’t tell if your private key was stolen and is in someone else’s possession. Anyone that owns your private key would be able to sign SAML messages as if it was you, and therefore impersonate any identity on your system. If you are using SimpleSAMLphp as a service provider, and you use signatures for identity providers to verify your requests, anyone having your private key may be able to get attributes related to the users of the system as if it was you.

11. Finally, if you are running SimpleSAMLphp as an identity provider, you need to tell your users to change their passwords, regardless of your SimpleSAMLphp installation being compromised or not. Because your server was vulnerable, every time your users were authenticating themselves an attacker had access to their credentials, and therefore you need to assume all of them are compromised. Before going out and telling your users to change their passwords, you may want to make sure that no other services are using the same identity backend, or if there are, that they are not vulnerable to heartbleed. If you make your users change their passwords but other services using the same identity backend are still vulnerable, the new passwords will still be vulnerable and therefore changing them is useless. Make sure you have patched all your vulnerable services, and then you can tell your users to change their passwords.

On the contrary, if you are running SimpleSAMLphp as a service provider you never get access to user passwords, but it might be a good idea to ask the identity providers to assess the status of their servers with regard to this vulnerability, and take the appropriate actions.