Log4j 1.x is in the same boat as Logback. It can be exploited if you have control over the configuration. Here is what Apache has to say about it (see https://logging.apache.org/log4j/2.x/security.html):
Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.
As you can see, they recommend auditing your configuration, and nothing else. Misconfiguration does not warrant breaking existing versions. In my opinion, the vulnerability here is JNDI allowing remote connections by default. Merely supporting JNDI (or JDBC for that matter) is not an inherent vulnerability. Misusing them is. There is no way libraries can prevent an attacker from doing dangerous things if the whole JVM is already compromised through remote code execution.
For a logging framework - any code capable of accessing networks should be by default excluded compile-time (=from JAR) and only included by users who wish to use these features. There should be a distributable artefact with ONLY bare minimum log to a log-file functionality without any other bells and whistles code included.
I agree that this would be a reasonable percaution, but the current bugfix release breaks use-cases without deprecation. Even Log4j 2.x didn't outright break use-cases, they just changed to more secure default behavior. Logback's change in particular isn't even a fix, it is just a percaution. |