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

[flakshack]

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.

[flakshack]

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."