[cabfpub] CA Security Council's Blog Post on Heartbleed Bug Discovery

Ben Wilson ben at digicert.com
Wed Apr 9 19:36:06 UTC 2014


 

https://casecurity.org/2014/04/09/heartbleed-bug-vulnerability-discovery-imp
act-and-solution/ 

On April 7, 2014, a vulnerability in the OpenSSL cryptographic library was
announced to the Internet community. Aptly labeled as the Heartbleed bug,
this vulnerability affects OpenSSL versions 1.0.1 through 1.0.1f
(inclusive). The Heartbleed bug is not a flaw in the SSL or TLS protocols;
rather, it is a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat
functionality. The flaw is not related or introduced by publicly trusted
certificates and is instead a problem with server software.

Heartbleed Bug Discovery

The Heartbleed bug was uncovered by a group of security engineers from
Codenomicon and Neel Mehta from Google Security. According to The Heartbleed
Bug website hosted by Codenomicon:

"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 the SSL/TLS encryption
used to secure the Internet. SSL/TLS provides communication security and
privacy over the Internet for applications such as web, email, instant
messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the
systems protected by the vulnerable versions of the OpenSSL software. This
compromises the secret keys used to identify the service providers and to
encrypt the traffic, the names and passwords of the users and the actual
content. This allows attackers to eavesdrop on communications, steal data
directly from the services and users and to impersonate services and users."

Software bugs are part of every software release, and most software updates
or new versions of software include bug fixes. The features of the
Heartbleed bug that make it unique include:

*	Any Heartbleed-based attacks are not readily traceable. Because the
problem has existed for two years, most server operators using a vulnerable
version of OpenSSL likely don't have enough logs/monitoring to determine
whether a site was compromised.
*	The potential impact of the Heartbleed bug vulnerability is
difficult to measure. The Heartbleed bug was included in the 1.0.1 release
of OpenSSL on March 14, 2012 and was included in each additional release
through the OpenSSL 1.0.1f release.
*	The Heartbleed attack does not rely on other vulnerabilities to
compromise a site. Often, attacks necessitate that the attacker first
exploit a weak security practice to get a foothold in a system. 
*	The internet and security communities pushed OpenSSL 1.0.1 and
subsequent releases because they included TLS 1.1 and 1.2 which contained
fixes for vulnerabilities to other attacks in TLS 1.0, such as the BEAST
(Browser Exploit Against SSL/TLS) attack.

OpenSSL version 1.0.1 through 1.0.1f and 1.0.2-beta1 are vulnerable to the
Heartbleed Bug attack. The OpenSSL version 1.0.1g released yesterday fixes
the Heartbleed Bug. Note that earlier versions of OpenSSL branches 1.0.0 and
0.9.8 do not include the Heartbleed Bug vulnerability. The 1.0.2-beta2
version will contain the fix that is included in OpenSSL version 1.0.1g.

Heartbleed Bug Impact

If the servers in your SSL environment do not use OpenSSL, if your servers
use OpenSSL 1.0.0 or earlier, if your servers do not use OpenSSL
1.0.2-beta1, or if your servers are compiled without the heartbeat extension
enabled, then your environment is not vulnerable to the Heartbleed Bug
attack.

However, if your servers are running an OpenSSL version 1.0.1 through 1.0.1f
with the heartbeat extension enabled, then your environment is vulnerable to
a Heartbleed Bug attack. Although no Heartbleed Bug attacks have been
documented, it is impossible to know if the Heartbleed Bug vulnerability has
been exploited because the attack does not leave a trace. 

Solutions

If your servers are running OpenSSL versions 1.0.1 through 1.0.1f with the
heartbeat extension enabled, you should take the following actions as soon
and as quickly as possible to mitigate any possible damage:

1.	Upgrade your server to the latest version of OpenSSL (version 1.0.1g
or later).

Check your package manager for an updated OpenSSL package and install it.

If you do not have an updated OpenSSL package, contact your Service Provider
to obtain the latest version of OpenSSL.

2.	Rekey, reissue, and then revoke all certificates used with the
vulnerable version of OpenSSL.

To Upgrade Your Server

Check your package manager for an updated OpenSSL package and install it. If
you do not have an updated OpenSSL package, contact your Service Provider to
obtain the latest version of OpenSSL and install it.

Workarounds

Only use these workarounds if you cannot upgrade to the latest version of
OpenSSL. If you are unable to upgrade to the latest OpenSSL version, do one
of the following:

*	Rollback to OpenSSL version 1.0.0 or earlier.
*	Recompile OpenSSL with the OPENSSL_NO_HEARTBEATS flag.

To Rekey Your Certificates

Once the server has been patched, we recommend that you replace your
certificate with a new one using a new key pair, an operation commonly
referred to as a 'rekey'. To do this, you will need to generate a new CSR
and submit it to your CA so that they can reissue the certificate. Your CA
can help you generate the CSR and provide additional information about
rekeying your certificate. You should confirm with your CA that the old
certificate is revoked once you've installed the new one on your server.

Although the chance of an attacker obtaining a private key through
Heartbleed is unlikely, rekeying is a good precaution given the sensitive
nature of the information. We encourage any server operator affected by the
vulnerability to consult with their CA if they have questions about the
potential impact and risks. 

Other Suggestions

In addition to replacing affected private keys, server operators should
encourage users to change any passwords possibly leaked through the
vulnerability. Periodically changing passwords is a good security practice,
and this vulnerability gives system administrators a launching point to
affect change within their infrastructure. Of course, passwords should be
changed after the vulnerability is patched on the server to avoid leaking
the new password.

We encourage all users to use different passwords for various sites. Using
multiple passwords ensures that a compromise of account with one site will
not lead to a compromise of multiple accounts associated with the same email
or username.

Summary

Again, this vulnerability is not a flaw related to the protocols or the use
of digital certificates. Instead, the flaw is a result of a bug in the open
source program. Although this is a severe failure by the software developers
to detect a major vulnerability, CASC encourages industry participants to
focus on ways to prevent a reoccurrence of similar problems rather than
blamestorming. The CASC members fully support the initiatives to remedy this
vulnerability and look forward to working with the non-CA community in
ensuring a safe and secure Internet.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140409/dccc718f/attachment-0002.html>


More information about the Public mailing list