I have no idea where that might be used, but the only mitigation I can find is to remove JndiLookup.class from the jar (naturally you'll want to backup and test before rolling it out): This ships log4j 2.8.2 hidden in pentaho-solutions/system/karaf/system/org/ops4j/pax/logging/pax-logging-log4j2/1.10.2/pax-logging-log4j2-1.10.2.jar. However, 1.x is no longer supported and apparently has it's own vulnerability that was never patched up due to EOL, so I guess the question is how do we move Pentaho up to log4j2 v2.15? Here's what I was going from when trying to troubleshoot. I read up a little on it (not an expert on this btw), and I could not find the classes referenced in that vulnerability. We are also using community edition (9.1), but from everything I can tell, the original poster is correct in that Pentaho uses 1.x version, which I don't believe is affected by this weekend's log4j vulnerability. 1.x versions aren't even tested for security compliance by the log4j team anymore (you know, because EOL.) and they urge anyone using log4j to update to 2 in order to receive security updates. Pdi-ce 9.2 still uses a log4j jar from 2012 that hit EOL in 2015. The more I read about it, the more obvious it becomes that this is a way larger issue than we (as of this writing) understand. There's a questionably large RCE exploit announced today () that may or may not impact pdi. Keep an eye on the knowledge base article below: Subject: log4j security compliance - CVE-2021-44228
0 Comments
Leave a Reply. |