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 <[email protected]> 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
