The Apache Logging Services PMC has received the security report
referenced below. After analysis, we classified it as INVALID (works as
designed). In the interest of transparency and so that the community and
other researchers can benefit from the analysis, we are disclosing a
summary of it.
Report reference (Logging Services PMC / security archive):
https://lists.apache.org/thread/k38tg3hsbo7kl17psybp02nzl28lwloq
Disposition: INVALID -- works as designed; no CVE
TLP:CLEAR (this message may be redistributed without restriction)
The reporter was informed of this classification and of our intent to
publish this summary.
== Summary of the report ==
In Log4j Core, setting the legacy `log4j.configuration` system property
(which points at a configuration file) causes `ConfigurationFactory` to
call `System.setProperty("log4j1.compatibility", "true")`, engaging the
Log4j 1.x configuration parser. The reporter argued that this "silently
breaks" a documented opt-in contract, on the grounds that
`log4j1.compatibility` is documented as an explicit, default-`false`
gate for the legacy parser (which has known XXE and unsafe-reflection
behavior). Three related points were raised:
1. Presence of `log4j.configuration` force-enables
`log4j1.compatibility` process-wide (CWE-1188).
2. The same occurs via the `LOG4J_CONFIGURATION` environment variable
or a classpath `log4j2.component.properties` entry (CWE-1188).
3. In `log4j-1.2-api`, the gate reads the mutable system property at
call time rather than caching it at class-initialisation (CWE-642).
== PMC assessment ==
This is NOT a vulnerability. Every input involved -- the
`log4j.configuration` and `log4j1.compatibility` properties and the
referenced XML configuration file -- is operator-controlled
configuration, which is trusted input under our threat model:
https://logging.apache.org/security.html#threat-common-sources-configuration
A logging configuration can already instantiate arbitrary classes and
appenders; anyone able to set these properties or supply the
configuration file is already fully trusted. No trust boundary is crossed.
On the alleged contract: `log4j1.compatibility` gates the *programmatic*
use of `DOMConfigurator` and `PropertyConfigurator`. It has never gated
Log4j's support for the Log4j 1.x *configuration file formats*. Pointing
`log4j.configuration` at a Log4j 1.x configuration file enables that
support on its own, by design and for backward compatibility -- Log4j
has auto-detected `log4j.properties` and `log4j.xml` on the class path
since Log4j 1.0. No documented contract is broken.
On the three specific points:
1. The internal `System.setProperty(...)` call is an implementation
shortcut used to honor `log4j.configuration`. We agree it is inelegant
and can have undesired side effects, e.g., in a JVM shared by several
applications. That is a code-quality matter, not a vulnerability; we
invited a separate, non-security bug report to improve it.
2. Reading `log4j.configuration` from the environment
(`LOG4J_CONFIGURATION`) or from `log4j2.component.properties` is
standard, documented property resolution across operator-controlled
configuration surfaces. We did find and fix a documentation typo (the
environment variable had been written as `LOG4J_CONFIGURATION_FILE`).
3. Reading the property at call time rather than caching it is
intentional: Log4j Core supports runtime reconfiguration without event
loss, so these settings are deliberately not frozen at initialization.
This gate is not a security control.
== Documentation improvements ==
Because we suspect our documentation contributed to the confusion, we
opened a documentation-only issue and pull request:
https://github.com/apache/logging-log4j2/issues/4263
https://github.com/apache/logging-log4j2/pull/4264
These make the two properties self-contained and ensure that every
mention of XXE and XInclude, in both the documentation and the Javadoc,
sits next to a reference to our threat model.
== References ==
Threat model:
https://logging.apache.org/security.html
Migrating from Log4j 1:
https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#ConfigurationCompatibility
Questions and follow-up are welcome on this list or GitHub Discussions.
On behalf of the Apache Logging Services PMC,
Piotr P. Karwasz
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
