[jira] [Comment Edited] (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=17469668#comment-17469668 ] 

Ralph Goers edited comment on LOG4J2-3297 at 1/6/22, 4:23 AM:
--------------------------------------------------------------

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 set to a URL Log4j will attempt to load from the url. If it is not a URL Log4j will attempt to resolve it as a path to a file. 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.


was (Author: ralph.goers@dslextreme.com):
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)