4 ms·

It really re-enforces the idea of sane defaults. How many end users of a logging framework would even need JNDI functionality?

est 5y ago
> How many end users of a logging framework would even need JNDI functionality Serious question: Suppose you need to replace user ids with user names in your Java program logs, instead of writing LDAP lookups around every log line everywhere, you have to put it in some module no? How about wrap the logging framework?
- garblegarble 5y ago
  Why on earth would you want more PII in your logs?
- maherbeg 5y ago
  This should be done as a middleware or plugin into the library that is opt in rather than built in as a default.
- awestroke 5y ago
  Why would you do that? That sounds like a terrible idea, and a bad way to spend your limited development resources
- paulmd 5y ago
  translate it to a username once when the thread is issued from the pool (or in a pre-receive spring interceptor/JaveEE request filter) and set it into a MDC value, then just print the MDC value. Calling an external service for every single log message written is still, itself, insane from a performance sense. Not every call need necessarily be written but still, yikes, that's a lot of API calls, even if the LDAP is still machine-local that's a lot of latency for every request. of course the fun bit from the 2nd vulnerability is that the MDC implementation could still get at JDNI because it was doing a second layer of formatting, so doing this opened you up to JDNI attacks again - but that is the technically-correct answer for how you do that in a logging framework imo. You don't do it on-demand in a filter, you do it once per thread/request when the thread is issued or the request is received and put the result into MDC. If "ownership" of the thread changes, then clear and update the MDC again. The real problematic one that log4j2's JNDI support was originally implemented to solve, was "I have multiple WARs inside an application server, how do I know which one this log message came from" and that one is a bit tricker to answer generically. I think the lazy answer there would be to hardcode the application name into the logfile - just because it can be generated on the fly, doesn't mean it has to be, you can have a pattern that is like "[%d][myService][%level%]..." and myService is just a literal in the pattern. You can also get it programmatically from Spring or the JavaEE API itself somehow (don't know that one off the top of my head but I'm sure there's a way), and put it into MDC like other values... or put it in a service.properties file that also lists the service API version/etc (along with the short git commit and git commit time from git.properties built by gradle-git-properties, these are questions that people often end up asking when troubleshooting a service).

est 5y ago

> How many end users of a logging framework would even need JNDI functionality Serious question: Suppose you need to replace user ids with user names in your Java program logs, instead of writing LDAP lookups around every log line everywhere, you have to put it in some module no? How about wrap the logging framework?

garblegarble 5y ago
Why on earth would you want more PII in your logs?
maherbeg 5y ago
This should be done as a middleware or plugin into the library that is opt in rather than built in as a default.
awestroke 5y ago
Why would you do that? That sounds like a terrible idea, and a bad way to spend your limited development resources
paulmd 5y ago
translate it to a username once when the thread is issued from the pool (or in a pre-receive spring interceptor/JaveEE request filter) and set it into a MDC value, then just print the MDC value. Calling an external service for every single log message written is still, itself, insane from a performance sense. Not every call need necessarily be written but still, yikes, that's a lot of API calls, even if the LDAP is still machine-local that's a lot of latency for every request. of course the fun bit from the 2nd vulnerability is that the MDC implementation could still get at JDNI because it was doing a second layer of formatting, so doing this opened you up to JDNI attacks again - but that is the technically-correct answer for how you do that in a logging framework imo. You don't do it on-demand in a filter, you do it once per thread/request when the thread is issued or the request is received and put the result into MDC. If "ownership" of the thread changes, then clear and update the MDC again. The real problematic one that log4j2's JNDI support was originally implemented to solve, was "I have multiple WARs inside an application server, how do I know which one this log message came from" and that one is a bit tricker to answer generically. I think the lazy answer there would be to hardcode the application name into the logfile - just because it can be generated on the fly, doesn't mean it has to be, you can have a pattern that is like "[%d][myService][%level%]..." and myService is just a literal in the pattern. You can also get it programmatically from Spring or the JavaEE API itself somehow (don't know that one off the top of my head but I'm sure there's a way), and put it into MDC like other values... or put it in a service.properties file that also lists the service API version/etc (along with the short git commit and git commit time from git.properties built by gradle-git-properties, these are questions that people often end up asking when troubleshooting a service).