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

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

ASF subversion and git services commented on LOG4J2-3297:
---------------------------------------------------------

Commit e8dab8c5d652437ff61d2e797bfbe4e4e6cdd1bb in logging-log4j2's branch refs/heads/release-2.x from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e8dab8c ]

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)