Does Splunk Enterprise, including Universal Fowarders make use of Log4j (cfr CVE-2021-44228)?

[gdigrego]

Hi,

This question is related to CVE-2021-44228. 

As far as we could see/scan, Splunk binaries, including Universal Forwarders ones, do not rely on or use the Log4j library but we wanted to get some sort of "official confirmation" of this. Thanks if you can point any public document regarding this and regarding to Splunk potential exposure to this particular CVE. 

Best Regards.

[richgalloway · Accepted solution]

Here's the official word: https://www.splunk.com/en_us/blog/bulletins/splunk-security-advisory-for-apache-log4j-cve-2021-44228...

In summary:

Core Splunk Enterprise functionality does not use Log4j and is therefore not impacted. However, if Data Fabric Search (DFS) and Splunk Analytics for Hadoop (Hunk) product features are used, there is an impact because these product features leverage Log4j. If these features are not used, there is no active attack vector related to CVE-2021-44228.

[gdigrego]

Doing some additional preliminary researches, it seems that some Splunk components (like "splunk_archiver") and some TAs like the Tomcat one include the Log4j library.

Does not mean forcedly that these libraries are exposed to attackers of course ... 

[PickleRick]

Are you sure that TA for Tomcat utilizes log4j? Whatever for? It's supposed to parse logs, not generate them.

Anyway, just because some solution uses the vulnerable component doesn't mean that it's used in a vulnerable way. If you use log4j but only ever log static messages or generate dynamic logs but never use any user-supplied data for it and you fully control the contents of your logs at all times you have nothing to worry about.

The vulnerability is so serious in global scale because of two factors:

1) ubiquity of log4j - it's the most common logging framework for java used across many many solutions written in java

2) many of those solutions are public-facing and they do log user-supplied data by design (like access-logs).

So even though splunk's dbconnect is written in java and probably (haven't checked it) uses log4j for logging, the possible attack vector would need data manipulation on the monitored database server side. If you were monitoring a completely unknown dbserver somewhere on the internet, the risk would be significant. If you're just monitoring your internal infrastructure the risk is much lower next to negligible depending on your organization.

With vulnerability management it's always about assessing risks.

[gdigrego]

Hi @PickleRick and all,

The latest version (3.0.0) of the Splunk add-on for Tomcat includes some Log4j libraries (version 2.4.1) in this directory:

.../bin/java/jmx-op-invoke-1.1.0/lib

At this moment, we are using (and have customized) a previous version of that add-on which is having the Log4j libraries in these directories:

.../bin/java/jmx-op-invoke-1.0/lib/

and

.../bin/java/log-discovery-1.0/lib/

As we both said, the fact that these libraries are present in the install path do not forcedly means we are exposed of course.

But we have seen many vendors (including Splunk) that have started to build and deliver patches, as a good practice, which will include newer Log4j libraries versions (2.15.0 or above) known to be unexposed to that CVE.

I presume this will also be the case in the coming hours/days for the Splunk add-on for Tomcat.

BR 

[PickleRick]

Ahhh. For jmx querying. That's equally unlikely exploitable as dbconnect.

But yes, I understand the rationale behind patching. Especially that vulnerability scanners usually don't understand the context and would simply flag as critical every single instance of log4j in vulnerable version they found. 😉

[richgalloway]

AFAIK, Splunk is written in C and doesn't use log4j, but that could be old information.

Splunk is expected to make an announcement about the vulnerability later today.