You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by pk...@apache.org on 2025/03/20 11:28:35 UTC
(logging-site) branch feature/threat-model updated (46eab9b2 -> 97653c9c)
This is an automated email from the ASF dual-hosted git repository.
pkarwasz pushed a change to branch feature/threat-model
in repository https://gitbox.apache.org/repos/asf/logging-site.git
discard 46eab9b2 Improves Threat Model
discard 1770312b tmp
add ea24a845 Upgrade Jekyll docker file
add a521a2e4 Bump Jekyll to 4.4.1
add 02838907 Merge remote-tracking branch 'apache/main' into fix/stylesheet
new 97653c9c Improves Threat Model
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (46eab9b2)
\
N -- N -- N refs/heads/feature/threat-model (97653c9c)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
(logging-site) 01/01: Improves Threat Model
Posted by pk...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
pkarwasz pushed a commit to branch feature/threat-model
in repository https://gitbox.apache.org/repos/asf/logging-site.git
commit 97653c9c574ec29d5f30482514ed8b4e253352a9
Author: Piotr P. Karwasz <pi...@karwasz.org>
AuthorDate: Wed Mar 19 12:52:28 2025 +0100
Improves Threat Model
In this PR, we expand our threat model to cover:
- A better definition of the users we trust and those we don't.
- A list of resources that untrusted users should not control.
- A clear list of threats (with an example CWE) and whether Apache Logging Services considers that threat a vulnerability. You can appeal to the pope if you want, `PatternLayout` will never be anything else than a glorified `printf`.
---
_threat-model-common.adoc | 138 ++++++++++++++++++++++++++++++++++++++-------
_threat-model-log4j.adoc | 80 --------------------------
_threat-model-log4net.adoc | 61 --------------------
security.adoc | 8 +--
4 files changed, 120 insertions(+), 167 deletions(-)
diff --git a/_threat-model-common.adoc b/_threat-model-common.adoc
index 5698d334..5bd58573 100644
--- a/_threat-model-common.adoc
+++ b/_threat-model-common.adoc
@@ -16,31 +16,129 @@
////
[#threat-common]
-=== Common threat model
+= Common threat model
-Below we share the threat model shared by all Logging Services projects.
+All the logging frameworks maintained by Apache Logging Services (https://logging.apache.org/log4cxx/index.html[Log4cxx],
+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 contain the most common threats that a logging framework faces and the assumptions on the origin of various trusted data.
+Vulnerability reports that don't follow those assumptions will not be accepted and are **not** eligible for our
+https://yeswehack.com/programs/log4j-bug-bounty-program[Bug Bounty Program].
-[#threat-common-code-signing]
-==== Code signing
+[#threat-common-users]
+== User types
-All Logging Services software release distributions are signed using GPG using a key from the Logging Services PMC https://downloads.apache.org/logging/KEYS[KEYS file].
-Information on how to verify releases signatures are explained further in xref:download.adoc[the Download page].
-Thus, GPG signatures should be validated in your build process.
+Apache Logging Services distinguishes two kinds of users:
-[#threat-common-config-sources]
-==== Configuration sources
-All configuration sources to an application must be trusted by the programmer.
-When loading a configuration file from disk (especially when a monitor interval is configured to reload the file periodically), the location of the configuration file must be kept safe from unauthorized modifications.
-Similarly, when loading a configuration file over the network such as through HTTP, this should be configured to use TLS or a secure connection in general with strong authentication guarantees.
-This remote location must be kept safe from unauthorized modifications.
+Trusted Users::
++
+Application developers and administrators are considered **trusted** users.
+They have unrestricted access to all the features of the logging framework.
-For Java-based projects supporting JNDI or JMX,
-when configurations are modified through JMX, the JMX server should be safely configured to require authentication and a secure connection if being accessed over the network.
-When configurations are provided through JNDI, these should only use the `java` scheme for sharing configurations in a Java EE or Jakarta EE application service.
-JNDI-sourced configurations should not use other JNDI providers such as LDAP, DNS, or RMI, as all these providers are difficult to properly secure.
+Untrusted Users::
++
+All the other users are considered untrusted.
-[#threat-common-java-serialization]
-==== Java Object Serialization Stream Protocol
+[#threat-common-assets]
+== Data sources
-https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html[Java Object Serialization Stream Protocol] should not be used to deserialize data from untrusted sources.
+Logging systems read data from multiple sources that are controlled by both trusted and untrusted users:
+
+Trusted Sources::
++
+* Log4cxx, Log4j and Log4net **trust** environment variables, configuration properties, and configuration files.
+To keep them secure:
+** It is up to the deployer to ensure that untrusted parties do not have write access to these resources.
+** It is up to the deployer to ensure that these resources are transmitted through a confidential channel.
+** Non-confidential channels such as HTTP or JMX are disabled by **default** to prevent their unintentional usage.
+** If configuration files use interpolation features such as
+https://logging.apache.org/log4j/2.x/manual/lookups.html[lookups], it is up to the deployer to ensure that only lookups from trusted sources are used.
+It is up to the programmer to document thread context keys that can be considered as trusted.
+
+* The logging frameworks **trust** that the objects passed to the log statements can be safely converted to strings:
+** These frameworks should not be used to log deserialized data from untrusted sources.
See https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data[the related OWASP guide] for details.
+
+* If parameterized logging is used, the format string is **trusted**:
+** Programmers **should** use compile time constants as format strings to prevent attackers from mangling messages.
+See https://logging.apache.org/log4j/2.x/manual/api.html#best-practice-concat[Don't use string concatenation] for an example.
+
+Untrusted Sources::
+* Log4cxx, Log4j and Log4net **do not** trust log messages.
+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-threat]
+== Threats
+
+These are the most commonly encountered threats for users of Log4cxx, Log4j and Log4net:
+
+Log Injection (https://cwe.mitre.org/data/definitions/117.html[CWE-117])::
++
+Log injection is a common attack vector to hide malicious activity in an application.
+Regarding this threat:
+
+* **Unstructured layouts** such as https://logging.apache.org/log4j/2.x/manual/pattern-layout.html[Pattern Layout in Log4j] do **not** protect users from log injection.
+These layouts are meant for **human** and not computer consumption.
+* Log4cxx, Log4j and Log4net **must** prevent log injection in **structured** layouts, such as XML, JSON and RFC 5424.
+
+Supply chain attacks (https://cwe.mitre.org/data/definitions/1357.html[CWE-1357])::
+
+* Apache Logging Services projects **do** check the quality of our dependencies.
+* Deprecated components such as the
+https://logging.apache.org/log4j/2.x/manual/appenders/database.html#CassandraAppender[Cassandra],
+https://logging.apache.org/log4j/2.x/manual/appenders/message-queue.html#KafkaAppender[Kafka]
+and
+https://logging.apache.org/log4j/2.x/manual/appenders/database.html#CouchDbProvider[CouchDB]
+appenders are provided for backward compatibility purposes only.
+While we actively check for vulnerabilities in those components, they are _de facto_ unmaintained, and we discourage their usage in production.
+* All Apache Logging Services are signed with one of the keys in the Logging Services PMC
+https://downloads.apache.org/logging/KEYS[KEYS file].
+We do **not** support artifacts that do not have a valid signature, and we encourage users to always check the integrity of the downloaded components.
+Additional information on how to verify releases signatures is available on the xref:download.adoc[Download page]
+
+Information disclosure (https://cwe.mitre.org/data/definitions/200.html[CWE-200])::
++
+Since logging frameworks implement information disclosure by design:
+
+* It is up to the deployer to prevent unauthorized access to log files and to ensure that the appropriate log levels are configured.
+* It is up to the programmer to document which log levels and markers _might_ contain sensitive data.
+Attention should be brought to the fact that libraries on which an application depends might have a different log level and marker convention.
+* **Log masking** techniques are out-of-scope for Log4cxx, Log4j, and Log4net.
+It is up to the developer to ensure that sensitive data is properly masked **before** it is passed to the logging implementation.
+For this purpose, **third-party** frameworks like
+https://github.com/palantir/safe-logging[Safe-Logging]
+should be used.
+
+Log reliability (e.g. https://cwe.mitre.org/data/definitions/778.html[CVE-778])::
++
+Log4j is designed with **reliability** in mind:
+
+* By **default**, Log4j **should** deliver log events to the appropriate resource even during a reconfiguration event or will log an error.
+* While log events will be delivered to a resource, not all resources provide a confirmation mechanism.
+To ensure reliability along the entire logging pipeline, it is up to the deployer to use reliable transmission components:
+files, loopback network sockets or
+https://logging.apache.org/log4j/2.x/manual/appenders/message-queue.html[message-queue-based systems]
+for example.
+* Log4j provides configuration options that discard log events if the load on the application is high.
+Using these options invalidates the reliability guarantees.
+
+Denial of service (https://cwe.mitre.org/data/definitions/779.html[CVE-779])::
++
+Since our logging frameworks are designed with reliability in mind:
+
+* Our frameworks go to great lengths to minimize performance overhead, minimize latency and maximizing throughput.
+Since a universal solution does not exist, many configuration options exist to adapt the performance characteristics to a specific application.
+See
+https://logging.apache.org/log4j/2.x/manual/performance.html[Performance]
+for more information.
+* It is up to the deployer to ensure that the appenders can keep up with the logs written by using the appropriate appenders and configuring the appropriate level of logs.
+* It is up to the developer to ensure that log statements, which are not enabled, generate minimal overhead.
+See the
+https://logging.apache.org/log4j/2.x/manual/api.html#best-practice-concat[Log4j API Best Practices], for example.
+
+Improper neutralization of Special Elements (https://cwe.mitre.org/data/definitions/138.html[CWE-138])::
++
+* Log4cxx, Log4j, and Log4net **do** allow users to pass untrusted strings to log statements and thread context, except in the format string of parameterized logging, as mentioned above.
diff --git a/_threat-model-log4j.adoc b/_threat-model-log4j.adoc
deleted file mode 100644
index 08a123b9..00000000
--- a/_threat-model-log4j.adoc
+++ /dev/null
@@ -1,80 +0,0 @@
-////
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- https://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-////
-
-[#threat-log4j]
-=== Log4j threat model
-
-Below we share the threat model specific to link:/log4j[Log4j].
-
-[#threat-log4j-parametrized-logging]
-==== Parameterized logging
-
-When using a log message containing template parameters like `{}`, only the format string is evaluated for parameters to be substituted.
-The message parameters themselves are not evaluated for parameters; they are only included in the format string corresponding to their template position.
-The conversion of message parameters into a string is done on-demand depending on the layout being used.
-When structure-preserving transformations of log message data are required, the `Message` API should be used for logging structured data combined with a structured layout (e.g., `JsonTemplateLayout`).
-Format strings should be compile-time constants, and under no circumstances should format strings be built using user-controlled input data.
-
-[#threat-log4j-unstructured-logging]
-==== Unstructured logging
-
-When using an unstructured layout such as `PatternLayout`, no guarantees can be made about the output format.
-This layout is mainly useful for development purposes and should not be relied on in production applications.
-For example, if a log message contains new lines, these are not escaped or encoded specially unless the configured pattern uses the `%encode\{pattern}\{CRLF}` wrapper pattern converter (which will encode a carriage return as the string `\r` and a line feed as the string `\n`) or some other `%encode` option.
-Note that `%xEx` is appended to the pattern unless already present.
-Similarly, other encoding options are available for other formats, but pattern layouts cannot make assumptions about the entire output.
-As such, when using unstructured layouts, no user-controlled input should be included in logs.
-It is strongly recommended that a structured layout (e.g., `JsonTemplateLayout`) is used instead for these situations.
-Note that `StrLookup` plugins (those referenced by `${...}` templates in configuration files) that contain user-provided input should not be referenced by layouts.
-
-[#threat-log4j-structured-logging]
-==== Structured logging
-
-When using a structured layout (most layouts besides pattern layout), log messages are encoded according to various output formats.
-These safely encode the various fields included in a log message.
-For example, the `JsonTemplateLayout` can be configured to output log messages in various JSON structures where all log data is properly encoded into safely parseable JSON.
-This is the recommended mode of operation for use with log parsing and log collection tools that rely on log files or arbitrary output streams.
-
-[#threat-log4j-java-security-manager]
-==== Java Security Manager
-
-Log4j 3 no longer supports running in or using a custom `SecurityManager`.
-This Java feature has been deprecated for removal in Java 21.
-Log4j 2 includes partial support for running with a Security Manager.
-
-[#threat-log4j-log-masking]
-==== Log masking
-
-Log4j, like any other generic logging library, cannot generically support log masking of sensitive data.
-While custom plugins may be developed to attempt to mask various regular expressions (such as a string that looks like a credit card number), the general problem of log masking is equivalent to the halting problem in computer science where sensitive data can always be obfuscated in such a way as to avoid detection by log masking.
-As such, it is the responsibility of the developer to properly demarcate sensitive data such that it can be consistently masked by log masking plugins.
-This sort of use case should make use of the `Message` API for better control over the output of such data.
-
-[#threat-log4j-availability]
-==== Availability
-
-Log4j goes to great lengths to minimize performance overhead along with options for minimizing latency or maximizing throughput.
-However, we cannot guarantee availability of the application if the appenders cannot keep up with the logs being written.
-Synchronous logging can cause applications to block and wait for a log message to be written.
-Asynchronous logging can also cause applications to block and wait depending on the wait strategy and queue full policy configured.
-Configuring too large or too many buffers in an application can also result in out of memory errors.
-
-[#threat-log4j-compressing-logs]
-==== Compressing logs
-
-If log compression is used along with custom encryption where logs contain user-controlled input, then this can lead to a https://en.wikipedia.org/wiki/CRIME[CRIME attack] style vulnerability where a chosen-plaintext attack is combined with information leakage caused by how the compression algorithm handles different inputs.
-The simplest way to avoid this problem is to never combine compression with encryption when encoding user-controlled input.
diff --git a/_threat-model-log4net.adoc b/_threat-model-log4net.adoc
deleted file mode 100644
index 4bca1a06..00000000
--- a/_threat-model-log4net.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-////
- Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
- this work for additional information regarding copyright ownership.
- The ASF licenses this file to You under the Apache License, Version 2.0
- (the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
-
- https://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-////
-
-[#threat-log4net]
-=== Log4Net threat model
-
-Below we share the threat model specific to link:/log4net[log4net].
-
-[#threat-log4net-parametrized-logging]
-==== Parameterized logging
-
-When using a log message containing template parameters like `{0}`, only the format string is evaluated for parameters to be substituted.
-The message parameters themselves are not evaluated for parameters; they are only included in the format string corresponding to their template position.
-The conversion of message parameters into a string is done on-demand depending on the layout being used.
-When structure-preserving transformations of log data are required, a structured layout (e.g., `XmlLayout`) should be used.
-Format strings should be compile-time constants, and under no circumstances should format strings be built using user-controlled input data.
-
-[#threat-log4net-unstructured-logging]
-==== Unstructured logging
-
-When using an unstructured layout such as `PatternLayout`, no guarantees can be made about the output format.
-This layout is mainly useful for development purposes and should not be relied on in production applications.
-For example, if a log message contains new lines, these are not escaped or encoded.
-As such, when using unstructured layouts, no user-controlled input should be included in logs.
-It is strongly recommended that a structured layout (e.g., `XmlLayout`) is used instead for these situations.
-
-[#threat-log4net-structured-logging]
-==== Structured logging
-
-When using a structured layout (most layouts besides pattern layout), log messages are encoded according to various output formats.
-These safely encode the various fields included in a log message.
-For example, the `XmlLayout` can be used to output log messages in an XML structure where all log data is properly encoded into safely parseable XML.
-This is the recommended mode of operation for use with log parsing and log collection tools that rely on log files or arbitrary output streams.
-
-[#threat-log4net-log-masking]
-==== Log masking
-
-Log4Net, like any other generic logging library, cannot generically support log masking of sensitive data.
-While custom plugins may be developed to attempt to mask various regular expressions (such as a string that looks like a credit card number), the general problem of log masking is equivalent to the halting problem in computer science where sensitive data can always be obfuscated in such a way as to avoid detection by log masking.
-As such, it is the responsibility of the developer to properly demarcate sensitive data such that it can be consistently masked by log masking plugins.
-
-[#threat-log4net-availability]
-==== Availability
-
-Log4Net goes to great lengths to minimize performance overhead along with options for minimizing latency or maximizing throughput.
-However, we cannot guarantee availability of the application if the appenders cannot keep up with the logs being written.
-Logging can cause applications to block and wait for a log message to be written.
\ No newline at end of file
diff --git a/security.adoc b/security.adoc
index 288df590..ecd86895 100644
--- a/security.adoc
+++ b/security.adoc
@@ -22,7 +22,7 @@
The Logging Services Security Team takes security seriously.
This allows our users to place their trust in Log4j for protecting their mission-critical data.
-In this page we will help you find guidance on security-related issues and access to known vulnerabilities.
+On this page, we will help you find guidance on security-related issues and access to known vulnerabilities.
include::_log4j1-eol.adoc[]
@@ -48,11 +48,7 @@ We urge you to **carefully read the threat model** detailed in following section
It guides users on certain safety instructions while using Logging Services software and elaborates on what counts as an unexpected behaviour that has a security impact.
====
-include::_threat-model-common.adoc[]
-
-include::_threat-model-log4j.adoc[]
-
-include::_threat-model-log4net.adoc[]
+include::_threat-model-common.adoc[leveloffset=+1]
[#policy]
== Vulnerability handling policy