Logback offers the ability to load code like this. From my understanding the message of this issue is, that having this kind of functionality in any place is a possible issue. I interpret this as "an easily overseeable way to configure something insecure".
Yes, that is my understanding as well. Anytime a configuration file contains parameters that can be poisoned, an RCE attack can be mounted. The configuration file can be completely unrelated to logging.
As the news entry on the logback homepage mentions, the central thing required is write access to logback.xml. Since an attacker should never get access to configuration files (or even the classpath), this scenario is a lot harder to exploit than the current [*log4j 2.x*] issue. Both are operating on totally different scales of exploitability.
That is my impression as well. The vulnerabilities in log4j 2.x and logback/log4j 1.x are qualitatively very different. This difference is often obfuscated in the various articles recently published on the subject. |