This is an automated email from the ASF dual-hosted git repository.
ppkarwasz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/logging-site.git
The following commit(s) were added to refs/heads/main by this push:
new b257481b Add adversary model and revision section to common threat
model (#30)
b257481b is described below
commit b257481b9a42f695d9aab2eb0dbfe11d7b82fe68
Author: Piotr P. Karwasz <[email protected]>
AuthorDate: Sun May 17 22:01:43 2026 +0200
Add adversary model and revision section to common threat model (#30)
* 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]>
* fix: update adversary exclusions
Co-authored-by: Jan Friedrich <[email protected]>
---------
Co-authored-by: Jan Friedrich <[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..6ecb78cd 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 arbitrary code in the same process as the
logging framework. Code running in the same process shares the same trust level
as the logging framework itself; there is no boundary to enforce. This includes
code introduced through plugins, custom appenders, or other application
extensions.
+* 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.
