Apache Log4j vulnerability- Objective is not affected
Official statement from Objective:
The Objective applications (app server + gateway) currently use the log4j-api libraries (version 1.7.30).
The Log4Shell vulnerability is very specifically about the log4j-core librairies. We don’t use those anywhere.
We use the log4j api to loop external libraries that log via log4j api to our own event logger.
And in the apigateway (springboot) it is used to loop through to logback (which is the default springboot log frame)
Like many apache libraries, a particular domain, in this case log4j, consists of a whole set of sub-components that an application implementer uses the necessary parts of…
Like many other applications, we can also state the following:
Objective does not include the Log4j libraries that are affected by the recent remote code injection vulnerability, and for this reason is NOT affected by this vulnerability.
Even though the Log4j APIs are included, as separate log manager is used, which does not include the affected JNDI lookup capability.
Some references / additions:
================
Source: Apache Log4j Security Vulnerabilities (https://logging.apache.org/log4j/2.x/security.html)
Fixed in Log4j 2.15.0
CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.
Severity: Critical
Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1
Descripton: Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.
Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
>> the vulnerability is clearly situated in log4j-core-*.jar
================
Bron: Springboot https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
Log4J2 Vulnerability and Spring Boot
DECEMBER 10, 2021, As you may have seen in the news, a new zero-day exploit has been reported against the popular Log4J2 library which can allow an attacker to remotely execute code. The vulnerability has been reported with CVE-2021-44228 against the log4j-core jar and has been fixed in Log4J v2.15.0.
Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable.
================
If there are any additional questions and/or concerns, contact info@objt.com
