Seeing as Splunk is deployed with its own bundled openssl binary and libs, and seeing as compromise of the issue (CVE-2014-0160) is undetectable, what action can we take to protect against it and replace the bundled OpenSSL, SSL certificate and keys to ensure that everything remains secure?
I'm asking specifically in the view of managing a v5 deployment which we do not want to take up to v6 at present. (And yes this is an Enterprise deployment, but I am asking for the benefit of the wider audience, too.)
Having just dug a little further, it appears that v5.0.5 uses OpenSSL 0.9.8, which is not vulnerable. Question is, what about 5.0.8 which I was looking to deploy very soon.
Ok, I've dug deeper still, (using rpm2cpio to pry into the rpms)
rpm2cpio ${splunk_rpm} | rpm2cpio | cpio -itv | grep -i ssl
yields the following results (amongst others):
lr-xr-xr-x 1 root root 15 Mar 21 00:48 ./opt/splunk/lib/libssl.so -> libssl.so.0.9.8
-r-xr-xr-x 1 root root 332528 Mar 21 00:48 ./opt/splunk/lib/libssl.so.0.9.8
...
-r--r--r-- 1 root root 6279 Mar 21 00:48 ./opt/splunk/share/splunk/3rdparty/Copyright-for-openssl-0.9.8y.txt
The conclusion is that version 5 is not vulnerable in any of its guises to date. Only version 6 users are at risk.
It should be noted that this problem does exist for all version 6 releases to date, as they are ALL linked to the same vulnerable version of OpenSSL (1.0.1e).
A blog entry has just been published confirming this and progress so far in addressing the problem.
A further blog entry has now been published announcing a fix release available for download.
Splunk 6.0.3 has been released, which that patches Heartbleed and a separate TLS vulnerability
The Splunk Universal Forwarders 6+ are also vulnerable.
Just a quick note that when you have updated your system openssl you can actually force splunk to use those libraries by symlinking. This will make your splunk instance secure while waiting for the update.
At least worked for me.
A good intermediate solution for those on v6.
Splunk version 6.0 and later are vulnerable. no other versions are vulnerable.
We have a fix checked in and are currently in the process of testing our patch. We will be posting bits as soon as possible, and there will be information available at our security portal, http://www.splunk.com/page/securityportal
Note: Unless you have a public-facing, externally-accessible Splunk instance, you likely have very little exposure due to this vulnerability. That said, we are working very hard to deliver the patch as soon as possible, and to ensure that the patch we publish is of high quality.
I'm running v6.2, which is vulnerable. Any timeline for getting updates for it?
My system level openssl is patched, but Splunk is being deployed with its own openssl, and that one just makes the whole system vulnerable.
Let's consolidate this into http://answers.splunk.com/answers/130943/openssl-security-bug
Having just dug a little further, it appears that v5.0.5 uses OpenSSL 0.9.8, which is not vulnerable. Question is, what about 5.0.8 which I was looking to deploy very soon.
Ok, I've dug deeper still, (using rpm2cpio to pry into the rpms)
rpm2cpio ${splunk_rpm} | rpm2cpio | cpio -itv | grep -i ssl
yields the following results (amongst others):
lr-xr-xr-x 1 root root 15 Mar 21 00:48 ./opt/splunk/lib/libssl.so -> libssl.so.0.9.8
-r-xr-xr-x 1 root root 332528 Mar 21 00:48 ./opt/splunk/lib/libssl.so.0.9.8
...
-r--r--r-- 1 root root 6279 Mar 21 00:48 ./opt/splunk/share/splunk/3rdparty/Copyright-for-openssl-0.9.8y.txt
The conclusion is that version 5 is not vulnerable in any of its guises to date. Only version 6 users are at risk.
It should be noted that this problem does exist for all version 6 releases to date, as they are ALL linked to the same vulnerable version of OpenSSL (1.0.1e).
A blog entry has just been published confirming this and progress so far in addressing the problem.
A further blog entry has now been published announcing a fix release available for download.
As is already noted in the answer above (note the mention of the blog post 19 hours ago).
details about splunk 6.*
http://blogs.splunk.com/2014/04/09/splunk-and-the-heartbleed-ssl-vulnerability/
this is correct. see my answer for more info.