[
https://issues.apache.org/jira/browse/LOG4J2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493650#comment-17493650
]
ASF subversion and git services commented on LOG4J2-3297:
---------------------------------------------------------
Commit 3bd53c14f53c8178320a95fd27be8eac05081257 in logging-log4j2's branch
refs/heads/release-2.x from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=3bd53c1 ]
LOG4J2-3297 - Limit loading of configuration via a url to https by default
> 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
> Assignee: Ralph Goers
> 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)
