The Apache Logging Services PMC has received the security report
referenced below. After analysis, we classified it as HARDENING: not a
vulnerability, but a defense-in-depth improvement worth making. 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/g3jd6363tgk2tr47xrj1mc5r37hfz197
Reporter: Yu Bao from PayPal Cybersecurity Team
Disposition: HARDENING -- not a vulnerability; no CVE; tracked in a
public issue
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 ==
When `NoSqlAppender` is configured with a layout that returns a
`MapMessage` (for example `MessageLayout`), `NoSqlDatabaseManager`
copies every key/value pair of the message into the NoSQL document
without filtering reserved field names. With the CouchDB provider, a
`MapMessage` key named `_id` becomes the document's real `_id`, and an
`_id` starting with `_design/` creates or overwrites a design document,
which may contain server-side JavaScript executed by CouchDB. The
reporter argued that an attacker able to influence the *keys* of a
logged `MapMessage` could therefore install a malicious design document
(CWE-915) and reproduced this against a live CouchDB 3.5.2 server. The
report explicitly lists as a precondition that the application populates
the field names, not merely the values, of the message from externally
influenced data, and proposes both rejecting or prefixing
underscore-prefixed keys and documenting that field names are trusted
verbatim.
== PMC assessment ==
This is NOT a vulnerability. As the report itself notes, the attack
requires control over the field names of a structured log message. Under
our threat model these are structural identifiers, chosen by the
application developer and trusted, in the same way as the `MSGID` and
`SD-ID` fields of an RFC 5424 message. Routing untrusted data into them
is application misuse and is out of scope:
https://logging.apache.org/security.html#threat-common-sources-structural
The other preconditions are operator-controlled configuration: a `NoSql`
appender with a `MapMessage`-returning layout, and the CouchDB provider,
which is a deprecated component kept for backward compatibility only:
https://logging.apache.org/security.html#threat-common-threat
== Hardening ==
This is why we classified the report as HARDENING rather than INVALID:
the threat model allows the framework to reject a malformed structural
identifier instead of silently accepting it, and a logging library
installing a design document on a CouchDB server is not something any
user of `NoSqlAppender` would expect. A `MapMessage` key that collides
with a provider-reserved field name is a reasonable candidate, and it
matches the reporter's first remediation proposal, so we opened a public
hardening issue:
https://github.com/apache/logging-log4j2/issues/4331
Independently, `log4j-couchdb` depends on the unmaintained LightCouch
client and is scheduled for removal in an upcoming minor release.
== References ==
Threat model:
https://logging.apache.org/security.html
NoSQL appender documentation:
https://logging.apache.org/log4j/2.x/manual/appenders/database.html#NoSqlAppender
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]
