[
https://issues.apache.org/jira/browse/LOG4J2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469668#comment-17469668
]
Ralph Goers commented on LOG4J2-3297:
-------------------------------------
By default, Log4j looks for one of log42-test.[yaml, json, properties, xml] or
log4j2.[yaml, json, properties, xml] on the classpath. If the
log4j2.configurationFile system property is a URL Log4j will attempt to load
from the url. If logging.auth.username and logging.auth.password are set as
system properties Log4j will use them for basic authentication. If the user
desires some other form of authorization they can implement an
AuthorizationProvider and specify the class name on the
log4j2.authorizatoinProvider system property. All of these properties may be
defined in a file named log4j2.component.properties on the classpath instead of
specifying them on the command line.
> 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)
