Why is OPENSSL vulnerability still showing in latest release?

[tsondo]

Greetings,

We started seeing OPSNSSL vulnerabilities on all of our Splunk forwarders and the main engine this week. The advisory tells us we must use OPENSSL 3.0.8 or newer. Since OPENSSL is now on 3.1.2, I really thought the latest Splunk updates would fix the problem. I have just updated all forwarders to 9.1.0.1 and the main engine to 9.1.0.2, and it is now showing OPENSSL at 3.0.7. When will Splunk issue an update to address this and get OPENSSL to at least 3.0.8? 

[ClausBom]

I'm getting punked for this from our Vuln.mgt team too. They refer to a " CVE-2023-3446 - OpenSSL 1.0.2 < 1.0.2zi Vulnerability". 
Apparently, there's a file '/opt/splunk/lib/libcrypto.so.1.0.0' that existed for years, that all of a sudden is a problem to Nessus - but I can't find anything about it from Splunk?

I just tried to do an upgrade all the way from 6.5.2 to 9.1.0.2, but nothing changes - except the timestamp on the file.

[mp1]

yes, still we observed vulnerability  openssl libraries files having 1.0.2zi FIPS with latest SplunkForwarder 9.2.0.1 as below.

# cat /opt/splunkforwarder/etc/splunk.version
VERSION=9.2.0.1
BUILD=d8ae995bf219
PRODUCT=splunk
PLATFORM=Linux-x86_64

Library files

r-xr-xr-x. 1 splunk splunk 475784 Feb 7 00:48 libssl.so.1.0.0

r-xr-xr-x. 1 splunk splunk 2996816 Feb 7 00:48 libcrypto.so.1.0.0

How to mitigate this vulnerability ?

[PickleRick]

Have you read anything that has been written in this thread? Have you checked what openssl version is used here? (I'm talking about the actual library version, not the filename).

How have you "observed vulnerability"? Again - Nessus "detected" it by checking filename?

I'm all for vulnerability scanning but it should be performed properly, not just "run scanner with default settings and assume every finding is a true positive".

[tsondo]

If no one from Splunk chimes in with an expected patch date I will put in an official ticket. I would hope that a vulnerability listed as severe would have their full attention by now.

[josh_beverly]

did anybody ever get an answer on this? i can also put a ticket in but im being hounded by security team to get this looked at. nessus is also the tool they're using to complain to us about it.

[PickleRick]

Tell your security team to obsess over something more relevant.

See the original OpenSSL advisory - https://www.openssl.org/news/secadv/20230719.txt

Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available.

Your security team apparently didn't bother to verify what kind of vulnerability it was or if it was relevant in your situation in the first place. It's just the mechanical "we got a finding from our Nessus, we want to make you to get rid of it with no effort on our side, not even confirm that it's a real finding".

[tsondo]

In my case it is a DoD system and the openssl hits reference three nist concerns:

CVE-2023-2975 

CVE-2023-3446 

CVE-2023-3817 

I linked the nist articles, but apparently that isn't allowed. You can search them out if you want to.

These are all considered medium vulnerabilities, except that under DoD the last one, authentication gets bumped up a notch because it is authentication related.

OpenSSL has already addressed them. The question is when will Splunk integrate them into their own install packages. Going back to DoD and saying that it really isn't a big deal and I'm not going to fix it won't fly.

The options are: get a vendor patch, get instructions from the vendor on how to patch it without an update, or update it without vendor support and hope you don't break anything.

[ClausBom]

Well... if it wasn't for this line, in that advisory: 

OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

I guess I could tell them to focus on real problems... But Nessus complaints about $HOME/lib/libcrypto.so.1.0.0 in both Enterprise and Universal Forwarder - so they might have a right to obsess?
Splunk might not use this old stuff - but why isn't it removed then?

[PickleRick]

Just because the _file_ is named libssl.so.1.0.0 it doesn't mean that the actual library version is that ancient. It's a naming convention for the linker so if a library with version 1.0.0. is requested, the file is used.

(12:49:37) (splunk@mon1:~)
$ grep -Poa '1\.0\.2\S+' /opt/splunk/lib/libssl.so.1.0.0 
1.0.2zg-fips
1.0.2zg-fips
1.0.2zg-fips
1.0.2zg-fips
(12:50:09) (splunk@mon1:~)
$ /opt/splunk/bin/splunk cmd openssl version
OpenSSL 1.0.2zg-fips 7 Feb 2023
(12:50:15) (splunk@mon1:~)
$ cat /opt/splunk/etc/splunk.version 
VERSION=9.1.0.2
BUILD=b6436b649711
PRODUCT=splunk
PLATFORM=Linux-x86_64

Which corresponds to https://advisory.splunk.com/advisories/SVD-2023-0613

(same goes for UFs - see https://advisory.splunk.com/advisories/SVD-2023-0614 )

EDIT: Nessus is notorious for flagging hosts as vulnerable only by checking the reported file/package version which is annoying in case of distros which backport fixes into earlier versions (debian stable?). And security teams are notorious for not checking the actual findings 😉

[TarnishedMalwar]

I have the UFW 9.2.0.1 and still got the OpenSSL 1.0.2zi-fips, it's def not the same version you are pointing here. And to be sure I checked runing the splunk cmd openssl version. 

[tsondo]

No one has contacted me. I put in a support ticket today. I requested either an expected date for a newer version of OpenSSL to be added, or instructions on how to do it manually without compromising functionality or future upgrades. When I get an answer from them, I will post it.

[ClausBom]

I've raised a support ticket on this as well. I'll keep you updated on the outcome - if any 🤔

[ClausBom]

So, answer from Splunk Support:

You should not remove file libcrypto.so.1.0.0, it is part of libraries. This file exists in fresh new 9.1.0.2 Splunk installation too, so it is not part of old upgrade.

Splunk version 9.1.0.2 uses OpenSSL 1.0.2zg.

Topic about CVE-2023-3446 vulnerability was send to developer team.

In the meantime, Tennable apparently found out, that they'd been a bit premature... OpenSSL disappeared from their scannings... 🙄😤