After reading through it's a pretty bad feature. It should have been blocked. The very nature of what it does is terrible.

Some background:

JNDI alone is fine. You want to load code remotely and run it? Fine. You can do that already in other ways. No issue with JNDI here, go ahead and use it on your server in a controlled way that doesn't involve user input.

Log4j has a 'routing appender' that can conditionally write to different logs depending on the content being logged. https://logging.apache.org/log4j/2.x/manual/appenders.html#R...

I can see a use to string match and send logs different ways.

Now unfortunately this patch flat out uses the 'routing appender' to look for incoming log statements with the pattern ${jndi:logging/context-name} and load that remote JNDI class.

This is such a terrible idea that doesn't pass the sniff test. The person who approved this should have simply read the description of what it does. After matching the pattern ${jndi:logging/context-name} it puts that match into a string 'key' and runs ctx.lookup(convertJndiName(key));

It's similar to someone submitting a patch that says "I want to run eval(user_input)". The only difference is that lookup(convertJndiName()) is a little bit obfuscated since it's not called eval(). I guess the review could be mistaken that it's harmless?. Still i think it's a bad smell. I'm worried for this project. It's probably worth going through everything that 'implements StrLookup' and seeing what they do in the 'lookup(final LogEvent event, final String key)' function. Both event and key are user generated content.

The key thing is that one of the directory services you can use via JNDI is "java", which is a process-local configuration store present by default in enterprise (Java EE) applications. An enterprise web server can run multiple "applications" at once, and each one gets its own configuration in the java directory service.

So, if you have defined a configuration variable app-name-for-logging, then you can look up:

  java:comp/env/app-name-for-logging

to get the value. If you are writing a generic logging utility which works across many applications, it might be useful to use this to choose the log file, or just include it in the log output.

The easiest implementation of this was just to allow generic JNDI lookups, which includes LDAP.

What i can't explain is why anyone would legitimately use this feature to make JNDI lookups. It should have been scoped to only lookups in java:comp/env, not arbitrary ones.

I haven't validated this assumption but it looks like the patch was rather naive and added the jndi lookup to the Interpolator class and only tested for its usage in the configuration. Being unaware that the interpolator also runs on the full message.

poor woonsan :(

The feature request and feature were written by the same person.

While I can see why this would be useful (in very strict cases), one can always wonder if there was an ulterior motive to developing this "feature"

And of course, it's one thing to parse a jdni entry in a config setting, another to parse every single log message