Add Sinks section to the common threat model#38
Open
ppkarwasz wants to merge 1 commit into
Open
Conversation
Adds a Sinks section, the counterpart of the existing Sources section, closing the sink-side gap deferred in #32 ("active versus passive sinks, and downstream-destination trust"). The section states three things: 1. Sinks are the destinations an appender writes to. Unlike sources, which range from trusted configuration to untrusted content, every sink is operator-configured and therefore trusted, including destinations created dynamically at runtime (for example a Routing appender that interpolates a file path). 2. Destination integrity is a deployer responsibility. An adversary who can write to a log destination, for example by planting a symbolic link where a file appender creates its output, can already tamper with the logs directly, so the frameworks do not defend a destination they were configured to trust. A report that assumes such write access is out of scope. 3. A passive sink consumes our output as the format the layout produced, and we own the correctness of that format. An active sink re-interprets well-formed output in another language and acts on it (a terminal executing ANSI escape sequences, for example), which we do not own. The boundary is whether the framework emitted output malformed in its own format (ours to fix) or well-formed output that a sink chose to re-interpret (out of scope). The two worked examples are precedents: CVE-2025-54812 (Log4cxx HTML layout emitting malformed HTML) is a defect we published, while the class of CVE-2025-55754 (Apache Tomcat, ANSI escape sequences interpreted by a Windows console) is one we do not treat as a vulnerability. Dependent edits: the Log Injection threat now lists the HTML layout and cross-references the passive/active distinction; the out-of-scope adversary list adds the destination-write-access case and the active-sink re-interpretation case. This is normative and requires PMC review before merge. Assisted-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a Sinks section, the counterpart of the existing Sources section, closing the sink-side gap deferred in #32 ("active versus passive sinks, and downstream-destination trust").
The section states three things:
Sinks are the destinations an appender writes to. Unlike sources, which range from trusted configuration to untrusted content, every sink is operator-configured and therefore trusted, including destinations created dynamically at runtime (for example a Routing appender that interpolates a file path).
Destination integrity is a deployer responsibility. An adversary who can write to a log destination, for example by planting a symbolic link where a file appender creates its output, can already tamper with the logs directly, so the frameworks do not defend a destination they were configured to trust. A report that assumes such write access is out of scope.
A passive sink consumes our output as the format the layout produced, and we own the correctness of that format. An active sink re-interprets well-formed output in another language and acts on it (a terminal executing ANSI escape sequences, for example), which we do not own. The boundary is whether the framework emitted output malformed in its own format (ours to fix) or well-formed output that a sink chose to re-interpret (out of scope).
The two worked examples are precedents: CVE-2025-54812 (Log4cxx HTML layout emitting malformed HTML) is a defect we published, while the class of CVE-2025-55754 (Apache Tomcat, ANSI escape sequences interpreted by a Windows console) is one we do not treat as a vulnerability.
Dependent edits: the Log Injection threat now lists the HTML layout and cross-references the passive/active distinction; the out-of-scope adversary list adds the destination-write-access case and the active-sink re-interpretation case.
This is normative and requires PMC review before merge.
Assisted-By: Claude Opus 4.8 noreply@anthropic.com