[jira] [Commented] (LOG4J2-3297) Disable remote loading of log4j configuration to prevent MiTM Attacks

["Ralph Goers (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466514#comment-17466514 ] 

Ralph Goers commented on LOG4J2-3297:
-------------------------------------

This would not qualify for a CVE. Simply doing bad or incorrect things isn't a security issue. We have many things that fall into this category that could fall into "disable by default". We are looking into how to best achieve that without needing a thousand system properties.

> Disable remote loading of log4j configuration to prevent MiTM Attacks
> ---------------------------------------------------------------------
>
>                 Key: LOG4J2-3297
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3297
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.17.1, 2.17.0
>            Reporter: Peter Malone
>            Priority: Major
>
> The fix for *CVE-2021-44832* in release *2.17.1* of log4j-core prevents remote JNDI injection via the JDBC Appender.
> Given the nature of that CVE, an attacker requires local access to the configuration to be able to exploit it, OR in the rare chance the *log4j2.configurationFile* property is set to a remote HTTP location, an attacker can use a Man in the Middle Attack (MiTM) and inject their own malicious configuration which could disable logging for an application entirely.
> Is it possible to disable remote loading of log4j configurations entirely?
> If that feature is required, it may be necessary to create a log4j configuration server that provides signed configs to the application, but that seems like overkill to me. 
> I would opt for limiting the scope of the *log4j2.configurationFile* to local configurations, and if remote configuration is a feature you cannot remove, limiting it with a flag/variable and also limiting it to HTTPS for remote configs.
> I don't think the priority on this is extremely urgent, but someone may try to get a CVE under their belt by demonstrating this vector, and given the pressure you've been under I did not feel the need to get a CVE for this.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)