The following discusses FireMon and Log4j vulnerabilities. Vulnerabilities are exposed when the java package org.apache.logging.log4j.core.lookup.JndiLookup (or any code that references it) is leveraged in a very specific way that will cause the software to translate a crafted request into code that can be executed by the server.
Security Intelligence Platform
Security Intelligence Platform version 9+ is safe from these vulnerabilities. All customers running versions earlier than 9.0 are recommended to contact Support for advice or guidance on your upgrade plan to the latest version 9. Click here for information on version 8.x.
- CVE-2021-44228: Elasticsearch is the only FMOS component that uses Log4j. Version 7.8+ of Elasticsearch utilizes a recent version of the JDK (JDK9+) and is not susceptible to either remote code execution or information leakage. SIP is utilizing v7.10 of Elasticsearch, so is safe from this vulnerability.
- CVE-2021-45046: This vulnerability was raised on 12/14 after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Elasticsearch’s guidance for this vulnerability is that the Elasticsearch product is unchanged by this new vulnerability.
Status: Lumeta is safe from these vulnerabilities.
Lumeta uses version 1.2 of Log4j which is unaffected by CVE-2021-44228 as the JndiLookup Class required for this vulnerability to be exploited was not made available until Log4j version 2.x. (Note: changelog for Apache 2.0-beta9 - https://logging.apache.org/log4j/2.x/changes-report.html#a2.0-beta9"Add JNDILookup plugin. Fixes LOG4J2-313. Thanks to Woonsan Ko." under "Release 2.0-beta9 – 2013-09-14")
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default.
CVE info- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104
Lumeta architecture does not use JMS and hence it is not configured to use JMSAppender. Because of this, Lumeta is NOT vulnerable to this CVE.
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.
CVE info: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571
Lumeta application does not use SocketService. Because of this, it does not load any of the SocketServer classes from log4j. Lumeta is considered not vulnerable to this flaw since the affected code can not be reached.
Article is closed for comments.