Apache Log4j vulnerability issue

[jithumurugan]

Hello everyone,

I have seen recently that the apache community has reported about a more serious issue in log4j library: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Is this also applicable for the case of CTP tool? Do we have to upgrade the tool to use the specific version of log4j with the fix been implemented, kindly let us know the feedback, thanks

Regards
Jithu

[johnperry]

Jithru: None of the MIRC software (including CTP and TFS) uses log4j versions that are vulnerable to the attack. The vulnerable versions of log4j are 2.0 through 2.14.1. All the MIRC programs use log4j version 1.2.15. The vulnerability in question occurs when a string of a specific format is logged by Apache log4j. A server has to receive an HTTP request from an attacker and log something in the request that the attacker has crafted to trigger the vulnerability. None of the MIRC code logs strings from remote sites, so an attacker wouldn't have a way to exploit the vulnerability even if we were running a vulnerable log4j version. To exploit the vulnerability, the attacker uses a Java feature that automatically evaluates a string in the form ${...}. For example, if you run a Java program with a command line argument like this: java –jar program.jar ${java:version} the program will actually receive an argument string like: Java version 1.8.0_231 The problem arises when a server receives and logs something in a request (maybe a User-Agent header, for example) containing a string like: ${jndi:<protocol>://<ip:port>/<path-to-program-on-remote-site>} Log4j evaluates the string, triggering the Java Naming and Directory Interface (JNDI) framework to fetch and run whatever code the attacker's remote server supplies. The code doesn't even have to be a Java program; it can be anything supported by the local site, like an exe, for example, so this is a really bad problem. Apache has released a new version (2.16.0) that just turns off the JNDI capability in log4j, although it's not clear that this will be the final word on the subject. I have downloaded 2.16.0, but I haven't actually built it into anything yet. Log4j version 1 did not support the JNDI lookup mechanism, so it can't possibly have the problem. (It did include a JMSAppender which can do a JNDI lookup if configured in the log4j.properties file, but none of the MIRC code uses that appender.) I'll make new releases of everything when I'm satisfied that things have settled down, but the MIRC code currently in the field is not vulnerable to this attack, so I don't feel like this is an emergency. JP From: Jithu Murugan Sent: Wednesday, December 15, 2021 4:40 AM To: johnperry/CTP Cc: Subscribed Subject: [johnperry/CTP] Apache Log4j vulnerability issue (Issue #30) Hello everyone, I have seen recently that the apache community has reported about a more serious issue in log4j library: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 Is this also applicable for the case of CTP tool? Do we have to upgrade the tool to use the specific version of log4j with the fix been implemented, kindly let us know the feedback, thanks Regards Jithu — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.