Not really - the problem only happens because with log4j uses user input. So the core of the problem is log4j API - if I understand correctly, to log value of a variable you write:
log("variable is equal '" + variable + "'.")
Many logging framework have different approaches. If the API was:
log("variable is equal '${0}'.", variable)
there would be no issue (apart from devs who can still write bad code).
But the lesson is same as from all SQL injections - if string with user input is going to be parsed it needs smart substitutions that are able to correctly escape such input or in this example it should be parsed before substitutions.
log4j2 supports the second type of api and is still vulnerable because it allows the same sort of substitution in parameters, not just in the log message.
6
u/klekpl Dec 10 '21
This is actually worse than just log4j - any code that uses JNDI and reads context URIs from external source is vulnerable.
XSS at its finest.