Apache Log4j kwetsbaarheid- Objective is niet aangetast
Officieel statement van Objective:
De Objective applicaties (app server + gateway) gebruiken momenteel de log4j-api libraries (versie 1.7.30).
De Log4Shell vulnerability gaat heel specifiek over de log4j-core librairies. Die gebruiken we nergens.
De log4j api gebruiken wij om externe libraries die via log4j api loggen te laten doorlussen naar onze eigen eventlogger.
En in de apigateway (springboot) wordt die gebruikt om door te lussen naar logback (wat het standaard springboot log frame is)
Zoals zoveel apache libraries bestaat een bepaald domein, in dit geval log4j, uit een hele set van deel componenten waar een applicatie implementator de nodige delen van gebruikt…
Net zoals zoveel andere applicaties kunnen wij ook volgende stellen:
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.
Enkele referenties / aanvullingen:
================
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.
================
Indien er nog bijkomende vragen en/of bedenkingen zijn, contacteer info@objt.com
