3 ms·

I have read that ticket and the JNDI documentation multiple times and I still can't picture what it would look like to choose to use this. Can anyone show me a

I have read that ticket and the JNDI documentation multiple times and I still can't picture what it would look like to choose to use this. Can anyone show me a codebase that utilises this feature so we can see why?

deleted 5y ago
[deleted]
AnotherGoodName 5y ago
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#RoutingAppender 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.
twic 5y ago
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.

deleted 5y ago

[deleted]

AnotherGoodName 5y ago

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#RoutingAppender 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.

twic 5y ago

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.