This is an automated email from the ASF dual-hosted git repository. ppkarwasz pushed a commit to branch feat/adversary-model in repository https://gitbox.apache.org/repos/asf/logging-site.git
commit 221d0bd7dd11faaaba1b126110f4223047e76f6f Author: Piotr P. Karwasz <[email protected]> AuthorDate: Sat May 16 12:06:16 2026 +0200 Add adversary model and revision section to common threat model Extend the common threat model with two new sections: * "Adversary capabilities" defines the in-scope adversary and the capabilities it is assumed to have, and enumerates the out-of-scope adversaries whose reports will not be accepted. * "Revising this threat model" lists the conditions under which the document must be revisited. Self-referential and deeply nested object structures are explicitly placed out of scope. To keep disabled log statements cheap we call `toString()` on the passed parameters ourselves, so the safety of that call ultimately rests with the caller. This follows the CVE-2017-18640 precedent: SnakeYAML did not hang while _reading_ a "billion laughs" document, but it built a deeply nested map from it, and SnakeYAML, not the code that later operated on that map, was held responsible. Note tha [...] Open questions left for discussion: * The revision section does not yet define the process for modifying the threat model. This should likely require a public discussion followed by a public PMC vote. * Retroactivity: changes should apply only to versions published *after* the modification, not retroactively. If we adopt that, we should keep all previously published versions of this document available on the website. Assisted-By: Claude Opus 4.7 (1M context) <[email protected]> --- .../modules/ROOT/pages/_threat-model-common.adoc | 45 +++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc b/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc index 2ebd7b7d..6aacd248 100644 --- a/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc +++ b/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc @@ -22,7 +22,7 @@ All the logging frameworks maintained by Apache Logging Services (https://loggin https://logging.apache.org/log4j/index.html[Log4j] and https://logging.apache.org/log4net/index.html[Log4net]) face similar challenges from malicious actors. -The following sections outline the most common threats to logging frameworks and clarify the assumptions regarding the origin and trustworthiness of various data sources. +The following sections outline the most common threats to logging frameworks and clarify the assumptions regarding the origin and trustworthiness of various data sources and the capabilities assumed of potential adversaries. Vulnerability reports that do not adhere to these assumptions will not be accepted and are **not** eligible for the https://yeswehack.com/programs/log4j-bug-bounty-program[YesWeHack Bug Bounty Program]. [#threat-common-users] @@ -69,6 +69,33 @@ No particular input validation for log messages is necessary. * They **do not** trust the string representation of log parameters. * The logging frameworks do not trust neither the keys nor the values in the thread context. +[#threat-common-adversary] +== Adversary capabilities + +The threats listed below are evaluated against an adversary with a well-defined and limited set of capabilities. +Defining these capabilities clarifies which reports are in scope: a report that requires a capability not listed here is **not** considered a vulnerability. + +In-scope adversary:: ++ +An in-scope adversary is any party whose data reaches the logging framework **exclusively** through the untrusted sources described above. +Such an adversary is assumed to be able to: ++ +* Submit arbitrary byte sequences, including malformed text encodings and control characters (such as `CR`, `LF` and `NUL`), through log messages, the string representation of log parameters, and the keys and values of the thread context. +* Submit excessively long inputs, within whatever limits the calling application enforces. +* Submit input that resembles the framework's own interpolation or lookup syntax, including input that triggers recursive interpolation. + +Out-of-scope adversary:: ++ +The following adversaries are explicitly **out of scope**; a report relying on any of these capabilities will not be accepted: ++ +* An adversary able to modify environment variables, configuration properties, or configuration files: these are trusted sources (see <<threat-common-sources>>). +* An adversary able to execute code in the same process as the logging framework, including through plugins or other extensions added to the application. +* An adversary able to cause a self-referential or otherwise non-terminating object structure to be passed to a log statement. +The logging frameworks trust that logged objects can be safely converted to a string; converting such a structure is the responsibility of the calling code. +* An adversary observing side channels, such as the timing or memory behavior of the logging framework. +* A malicious destination of an appender (e.g. a hostile database, message broker, or mail server). +Appender destinations are configured by trusted users and are treated as an extension of the deployer. + [#threat-common-threat] == Threats @@ -157,3 +184,19 @@ Regarding this threat: -- + See xref:security/faq.adoc#deserialization[the FAQ entry on CWE-502] for the recommended alternatives. + +[#threat-common-revision] +== Revising this threat model + +This threat model reflects the current design of Log4cxx, Log4j, and Log4net. +It is **not** immutable: a revision is required whenever a change to one of the frameworks invalidates an assumption stated above. +In particular, this document must be revisited when any of the following becomes true: + +* A new public API is added that accepts a kind of input not yet covered by <<threat-common-sources>>. +* An existing entry point begins to accept input from a new source, changing whether that input is trusted or untrusted. +* A security-relevant default changes, or a configuration option that affects the security posture is added or removed. +* A framework gains a network listener or any other inbound surface of its own. +* A vulnerability report cannot be cleanly classified as either in scope or out of scope using the assumptions above. + +Internal refactors that do not change any of the above do **not** require a revision. +Proposed changes to this document are reviewed by the Apache Logging Services PMC.
