[
https://issues.apache.org/jira/browse/LOG4J2-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17466531#comment-17466531
]
Peter Malone commented on LOG4J2-3297:
--------------------------------------
[~rgoers] if I can explain it another way, loading configurations over HTTP
allows anyone on the same network as the application to intercept that request
and get log4j2 to load their own malicious configuration which could do
something like disable logging altogether, or to log information that shouldn't
be logged.
It's a classic MiTM vulnerability. That is the security issue with this
feature. It should be CVE worthy, albeit a pretty low CVSS, but again I didn't
feel the need to try go that route given the activity over the last few weeks.
Limiting remote configuration loading to HTTPS prevents this (as does turning
it off altogether), but you want to be sure with HTTPS/TLS that you are
verifying the certificate from the server hosting the configuration too, to
rule out dns spoofing attacks.
I hope this makes sense. It's been a long few days for me as well so I'm not
firing on all cylinders.
> 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)
