Recently a 0-day exploit got disclosed, that uses a security vulnerability in log4j which allows unauthorised remote code execution.
I'm wondering, what was the actual reason, why log4j has implemented this JNDI lookups, which have cause the vulnerability at all?
What would be an example for using this LDAP lookup feature in log4j?
Log4j is a popular logging framework used in Java (you can figure the popularity by seeing the widespread impact of the vulnerability). Log4j offers a specific feature, where you can add tokens to your logging string, that get interpolated to fetch specific data. E.g. "%d{dd MMM yyyy}" will insert the date at which the message was logged.
In the mean time JNDI (Java Naming and Directory Interface) is commonly used for sharing configuration settings to multiple (mirco)services.
You can imagine a situation where somebody would like to log configuration settings in e.g. error situations.
See this article explaining a bit
A Java based application can use JNDI + LDAP together to find a Business object containing data that it might need. For example, the following URL ldap://localhost:3xx/o=BusinessObjectID to find and invoke theBusinessObject remotely from an LDAP server running on either a same machine (localhost) on port 3xx or remote machine hosted in a controlled environment and goes on to read attributes from it.
The update it refers to mentions it as "LOG4J2-313: Add JNDILookup plugin." The motivation is found in the Apache JIRA entry
Currently, Lookup plugins [1] don't support JNDI resources. It would be really convenient to support JNDI resource lookup in the configuration.
One use case with JNDI lookup plugin is as follows: I'd like to use RoutingAppender [2] to put all the logs from the same web application context in a log file (a log file per web application context). And, I want to use JNDI resources look up to determine the target route (similarly to JNDI context selector of logback [3]).
Determining the target route by JNDI lookup can be advantageous because we don't have to add any code to set properties for the thread context and JNDI lookup should always work even in a separate thread without copying thread context variables.
[1] http://logging.apache.org/log4j/2.x/manual/lookups.html [2] http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender [3] http://logback.qos.ch/manual/contextSelector.html
The big problem with log4j, is that by default all string interpolation of all modules is turned on. In the mean time it has become opt-out, but it wasn't always.
