Deployment Architecture

SP-CAAAP3M - Tenable incorrectly reporting my instance vulnerable to privilege escalation running as non-root

flakshack
Explorer

This started out as a question, but is now just an FYI.  Similar to this post, this week I received a old vulnerability notice from Tenable about my Splunk instance.  We'd previously remediated this issue, so it was weird that it showed up again suddenly.

Vulnerability details:
https://packetstormsecurity.com/files/144879/Splunk-6.6.x-Local-Privilege-Escalation.html
https://advisory.splunk.com/advisories/SP-CAAAP3M?301=/view/SP-CAAAP3M
https://www.tenable.com/plugins/nessus/104498

The details in the articles are light, except saying to review the directions here for running Splunk as non-root:

https://docs.splunk.com/Documentation/Splunk/9.1.2/Installation/RunSplunkasadifferentornon-rootuser

Tenable also doesn't give details about exactly what it saw...it just says, "The current configuration of the host running Splunk was found to be vulnerable to a local privilege escalation vulnerability."

 

My OS is RHEL 7.x.  I'm launching Splunk using systemd with a non-root user and I have no init.d related files for Splunk.   My understanding is that launching with systemd eliminates the issue, since this way, Splunk never starts with root credentials anyway.

Per Splunk's own advisory, any Splunk system is vulnerable, if:

  1. Satisfied one of the following conditions
    a. A Splunk init script created via $SPLUNK_HOME/bin/splunk enable boot-start –user on Splunk 6.1.x or later.
    b. A line with SPLUNK_OS_USER= exists in $SPLUNK_HOME/etc/splunk-launch.conf


In my case, this is an old server and at one point, we did run the boot start command, which made changes to the $SPLUNK_HOME/etc/splunk-launch.conf line that sets the SPLUNK_OS_USER.  Although we had commented out the launch line, the Tenable regex is apparently broken and doesn't realize the line was disabled with a hash.  Removing the line entirely made Tenable stop reporting the vulnerability.  I assume their regex was only looking for "SPLUNK_OS_USER=<something>" so it missed the hash.

Anyway, hope this helps someone.

 

 

 

 

Labels (1)
0 Karma

flakshack
Explorer

I should add that this is confusion is probably caused because the Splunk advisory isn't as accurate as it could be (as I understand it).   Section 1b is not a vulnerability by itself, so the label for "1." should really say "both" of the following conditions, not "one."

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In January, the Splunk Threat Research Team had one release of new security content via the Splunk ES Content ...

Expert Tips from Splunk Professional Services, Ensuring Compliance, and More New ...

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

Observability Release Update: AI Assistant, AppD + Observability Cloud Integrations & ...

This month’s releases across the Splunk Observability portfolio deliver earlier detection and faster ...