Fix now available: Splunk and the Heartbleed vulnerability

Dear Splunk users,

This is an update to yesterday’s post on our handling of the OpenSSL Heartbleed vulnerability.  Thank you again for your patience and understanding as we spent the necessary time to prepare and test our fix for this important issue. As I mentioned yesterday, we are working hard to balance getting the fix out to you as quickly as possible while still spending sufficient time testing it to ensure a high quality delivery.

Take me to the fix!

As of now, Splunk Enterprise 6.0.3 is now available for download. This includes universal forwarder builds.

This release contains two fixes for vulnerabilities in OpenSSL:

  • CVE-2014-0160 – OpenSSL 1.0.1 TLS Heartbeat leaks sensitive information (also known as the “Heartbleed” vulnerability) (SPL-82696)
  • CVE-2013-4353 – Invalid TLS handshake could crash OpenSSL with a NULL pointer exception (SPL-78823)

Further information about these vulnerabilities is posted on our Security Portal.

Patches now available

Follow these links for the respective patch numbers:

What happens next?

We’ve made 6.0.3 available for download, and we’re now continuing to test our patches for each 6.x version. We’ll be posting patches for 6.0, 6.0.1, and 6.0.2 in the next few days now delivering patches for each affected version (see above). This means you have a choice as to whether you want to upgrade to 6.0.3 or patch your existing version. As always, we recommend upgrading to the latest version if possible.

As we’ve mentioned, the great majority of Splunk deployments are behind firewalls and/or require VPN access, and so do not have a high level of exposure as a result of this vulnerability. That said, once you’ve upgraded or patched, you should determine whether to revoke and reissue any SSL certificates you have in use based on your organization’s requirements.  Refer to “About securing your Splunk configuration with SSL” in the Splunk Enterprise documentation for details on how Splunk uses SSL.

If you are using the default certificates provided by Splunk, you can regenerate and reissue them using the utility provided in $SPLUNK_HOME/bin, although these certificates provide minimal protection on their own.  Note: You must either rename or move the original default certificates out of the way before you regenerate them.

If you are using your own self-signed or CA-generated certificates, you should revoke and reissue these certificates before changing your Splunk Web password(s).

As always, we recommend following the hardening guidelines in the “Securing Splunk” manual.



rachel perkins

Posted by