[
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)
