3 ms·
> But then we have log4j scanning all values instead of only format strings - I think it can be argued that this behavior is a critical bug and was never intend
by lultimouomo 5y ago
> But then we have log4j scanning all values instead of only format strings - I think it can be argued that this behavior is a critical bug and was never intended to begin with.
It was actually intended behavior, and this is what really boggles the mind!
Javadoc says explicitly that variable replacement is recursive, with cycle detection (which will throw! What happens to the log line in this case?) [0].
[0] https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/...
- culturedsystems 5y agoThat link is about variable replacement in config strings, which is intentionally recursive. It doesn't mention the use of the variable replacement mechanism when interpolating values into log messages, which is what makes this vulnerability so bad, and as far as I can see was not intentional.