[
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:32 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.
If the app is a spring boot app and it includes the log4j-spring-boot jar then
the location of the configuration file can be specified in bootstrap.yml as
{code:java}
spring:
application:
name: some-service
cloud:
config:
uri: https://spring-configuration-server.apache.org
username: sccuser
password: sccpassword
logging:
label: ${spring.cloud.config.label:master}
config:
"${spring.cloud.config.uri}/${spring.application.name}/default/${logging.label}/log4j2.xml?override=${spring.cound.config.uri}/${spring.application.name}/default/${logging.label}/log4j2-${spring.application.name}.xml"
auth:
username: ${spring.cloud.config.username}
password: ${spring.cloud.config.password} {code}
was (Author: [email protected]):
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.
If the app is a spring boot app and is includes the log4j-spring-boot jar then
the location of the configuration file can be specified in bootstrap.yml as
{code:java}
spring:
application:
name: some-service
cloud:
config:
uri: https://spring-configuration-server.apache.org
username: sccuser
password: sccpassword
logging:
label: ${spring.cloud.config.label:master}
config:
"${spring.cloud.config.uri}/${spring.application.name}/default/${logging.label}/log4j2.xml?override=${spring.cound.config.uri}/${spring.application.name}/default/${logging.label}/log4j2-${spring.application.name}.xml"
auth:
username: ${spring.cloud.config.username}
password: ${spring.cloud.config.password} {code}
> 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)
