Nagios Support Forum

Can I uninstall Log4j from my cluster?
I dont have any remote devices sending to my cluster using log4j. I want to know if I can simply remove the plugin with

Hi Ben,

The version of log4j that Nagios Log Server should be using is in the 1.2.x range which appears not to be vulnerable to the CVE-2021-44228 vulnerability and the CVE-2021-4104 vulnerability only affects specific configurations that we do not appear to be using; our dev team is continuing to look into it. These instances of the jar file are contained in the nagioslogserver directory and probably were not installed via the os packaging system:
With that being said if it is installed on your system via the packaging system, it should tell you what might be dependent upon it when you attempt to remove it. With that knowledge you should be able to make a determination if it's best to remove it or upgrade to a newer version, it shouldn't affect Log Server.

To check if it's installed separately: And if it is installed the syntax you had should do the job.

Thanks and Best Regards,
Keith

Apache Log4j 1.2 JMSAppender Remote Code Execution (CVE-2021-4104) (156103) from Nessus.

Path : /usr/local/nagioslogserver/elasticsearch/lib/log4j-1.2.17.jar
Installed version : 1.2.17
Fixed version : 2.16.0

While the 1.2.17 version was not vulnerable before we are now seeing this vulnerability. Looking for a patch to upgrade or remove if able. Looks like the update to the Nessus plugin was released on the 15th. A couple days after your post about this version not being vulnerable. Please advise on anything we can do to mitigate this without disabling the software.

Unfortunately removing the file will probably cause problems. The CVE-2021-4104 vulnerability is a little more complex than the first log4j vulnerability. It is our understanding, based upon the available information, that the vulnerability in the 1.2 versions of log4j depends upon a non-default configuration that we do not use; specifically logging to JMS. Redhat has a very good description of the vulnerability including recommendations for mitigation.

https://access.redhat.com/security/cve/CVE-2021-4104
https://bugzilla.redhat.com/show_bug.cgi?id=2031667


With that being said, nessus is still flagging it as a vulnerable version. Unfortunately we don't have access to the nessus plugin (156103) to confirm how it is identifying the instance as vulnerable, but the plugin information from Tenable indicates that it is using self reported version number only.

https://www.tenable.com/plugins/nessus/156103

The version of Apache Log4j on the remote host is 1.2. It is, therefore, affected by a remote code execution vulnerability when specifically configured to use JMSAppender.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Also Tenables' Research Research Highlights:

https://community.tenable.com/s/feed/0D53a00008E3hKzCAJ

156103 Apache Log4j 1.2 JMSAppender Remote Code Execution (CVE-2021-4104)

The version of Apache Log4j on the remote host is 1.2. It is, therefore, affected by a remote code execution vulnerability when specifically configured to use JMSAppender.

So it appears in this case that nessus isn't confirming the vulnerability but is just identifying that the potential vulnerability exists based upon version number. One thing you can try if you need to demonstrate that you've mitigated the risk would be to backup the jar file and then delete the JMSAppender.class file from the jar file as described by Redhat.
I tried this on one of my Log Server instances this morning and so far no problems have been noted; if it does cause problems you can always restore the jar file.
Hope this is useful.

Thanks and Best Regards,
Keith

This is helpful information. Unfortunately while the 1.2.17 version can be mitigated it is no longer supported and thus needs to be removed from our environment.

Are you aware of any efforts to mitigate this further by replacing the older version with 2.17.0 version?

We understand and share your concern; I have a query in with our Dev/QA team regarding your question and should have more information next week. Eventually the product and its dependencies will be updated however it's a question of workflow priorities and I don't have any visibility into that at the moment. Typically these types of issues are more complex than one would expect due to the number of operating systems and packages interactions involved.

Thanks and Best Regards,
Keith

Hello,

I am in the same situation where our security vulnerability tools have identified the older version of Log4j that is bundled with Nagios Log Server.

Has DEV/QA team provided an update on mitigating this finding?

Thanks!

We are also in the same boat. We have a 10 node cluster of NLS with plans to deploy this to 4 other sites and our security team came back with the same requirements. In our case we need either
- log4j updated to a supported version
- log4j removed
- replace Nagios Log Server with another product

Security is currently investigating other products since there is little expectation this will be resolved within an acceptable time window. May have better luck with a basic ELK stack.

Hi everyone,

I apologize for the radio silence here. We've had our devs looking into this the last couple of days, and are going to be looking into it further next week. I'm told we can expect an official response to this issue next week. Thank you very much for your patience in this.

its next week =D

this is still the official response : Any updates?
BTW we know that this issue came out of the blue for everyone. I understand that you guys have to make sure that you respond correctly and that takes time.