Hello Let me describe the idea for 3 recent and 3 older Log41 CVEs:
- CVE-2022-23302:Deserialization of untrusted data in JMSSink (org.apache.log4j.net.JMSSink#main()) - CVE-2022-23305: SQL injection in JDBC Appender - CVE-2022-23307: A deserialization flaw in the Chainsaw component - CVE-2021-4104: JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration - CVE-2020-9488: Improper validation of certificate with host mismatch in Apache Log4j SMTP appender - CVE-2019-17571: Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data Let me categorize these: - Chainsaw and JMSSink ones are kind of "external" and are not used in anyway at runtime. To use them, it'd be required to create a pax-logging-service OSGi fragment - JMSAppender, SocketAppender, SMTPAppender (if configured of course) require attacker to have write access to configuration file (config admin) - JDBCAppender (if configured of course) is indeed prone to SQL Injection https://reload4j.qos.ch/ is a fork created by Ceki Gulcu (original author of Log4j1 and Logback) where he wants to tackle all these problems and partially it's ok. The problem is with his approach to: - JDBCAppender - he's removed it - JMSAppender - he allowed JNDI name to be looked up only if the name is without schema part or has "java:" schema (JavaEE / JNDI spec) - this effectively prevents configuration like the one from https://activemq.apache.org/how-do-i-use-log4j-jms-appender-with-activemq if the ConnectionFactory is stored in LDAP (same for Artemis) When checking JMSAppender in reload4j, I checked how it's "fixed" in Log4j2 - and also there we can only use schema-less or "java:" schema topic names, so JMSConnectionFactory can only be configured when manually and locally configuring the JNDI binding for ActiveMQ. Now about mitigation - I had to take security scanners into account - these scanners usually don't bother if you (especially in OSGi environment) use the classes from available jars (like from KARAF_HOME/system repo) or not - these just mark your installation as vulnerable. So here's my plan: - users of Pax Logging 1.11.x will get two options: - new 1.11.x release without Chainsaw, JMSSink and with Socket/SMTPAppender backports from reload4j in pax-logging-service bundle - new 1.12.0 release based completely on 1.11.x, but simply without pax-logging-service - you'll have option to use Log4j2 or Logback implementations *ONLY* - users of Pax Logging 2.0.x will get two options: - new 2.0.x release without Chainsaw, JMSSink and with Socket/SMTPAppender backports from reload4j in pax-logging-log4j1 bundle - new 2.1.0 release based completely on 2.0.x, but simply without pax-logging-log4j1 - users of Pax Logging 1.10.x will get one option: - new 1.10.x release without Chainsaw, JMSSink and with Socket/SMTPAppender backports from reload4j - without ANY changes to JMSAppender I also want to suggest JDBCAppender fix different than its removal and send it to https://github.com/qos-ch/reload4j What do you think? kind regards Grzegorz Grzybek
