Pax Logging and recent Log4j1 CVEs (and one note about JMSAppender in Logj42)

[Grzegorz Grzybek <gr...@gmail.com>]

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