This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-site.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 18cca936 Automatic Site Publish by Buildbot
18cca936 is described below
commit 18cca936d8aa96cb6e181443a71cbeb189b7a0ed
Author: buildbot <[email protected]>
AuthorDate: Fri Aug 15 14:47:07 2025 +0000
Automatic Site Publish by Buildbot
---
content/feed.xml | 2 +-
content/security.html | 333 ++++++++++++++++++++++++++++++++------------------
2 files changed, 214 insertions(+), 121 deletions(-)
diff --git a/content/feed.xml b/content/feed.xml
index 5c4c8d17..1e8eefa0 100644
--- a/content/feed.xml
+++ b/content/feed.xml
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?><feed
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/";
version="4.4.1">Jekyll</generator><link href="/feed.xml" rel="self"
type="application/atom+xml" /><link href="/" rel="alternate" type="text/html"
/><updated>2025-07-28T18:07:27+00:00</updated><id>/feed.xml</id><title
type="html">Apache Software Foundation - Logging
Services</title><subtitle>Write an awesome description for your new site here.
You can edit this line in _ [...]
+<?xml version="1.0" encoding="utf-8"?><feed
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/";
version="4.4.1">Jekyll</generator><link href="/feed.xml" rel="self"
type="application/atom+xml" /><link href="/" rel="alternate" type="text/html"
/><updated>2025-08-15T14:47:05+00:00</updated><id>/feed.xml</id><title
type="html">Apache Software Foundation - Logging
Services</title><subtitle>Write an awesome description for your new site here.
You can edit this line in _ [...]
<p>A <strong>Vulnerability Exploitability eXchange (VEX)</strong> is a
machine-readable file used to indicate whether vulnerabilities in an
application’s third-party dependencies are actually exploitable.</p>
diff --git a/content/security.html b/content/security.html
index f8195924..e8c3ef9b 100644
--- a/content/security.html
+++ b/content/security.html
@@ -71,7 +71,7 @@
<div class="paragraph">
<p>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.</p>
+On this page, we will help you find guidance on security-related issues and
access to known vulnerabilities.</p>
</div>
<div class="admonitionblock warning">
<table>
@@ -135,163 +135,256 @@ It guides users on certain safety instructions while
using Logging Services soft
</tr>
</table>
</div>
-<div class="sect2">
-<h3 id="threat-common">Common threat model</h3>
-<div class="paragraph">
-<p>Below we share the threat model shared by all Logging Services projects.</p>
-</div>
-<div class="sect3">
-<h4 id="threat-common-code-signing">Code signing</h4>
-<div class="paragraph">
-<p>All Logging Services software release distributions are signed using GPG
using a key from the Logging Services PMC <a
href="https://downloads.apache.org/logging/KEYS";>KEYS file</a>.
-Information on how to verify releases signatures are explained further in <a
href="download.html">the Download page</a>.
-Thus, GPG signatures should be validated in your build process.</p>
</div>
</div>
-<div class="sect3">
-<h4 id="threat-common-config-sources">Configuration sources</h4>
-<div class="paragraph">
-<p>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.</p>
-</div>
-<div class="paragraph">
-<p>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
<code>java</code> 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.</p>
-</div>
-</div>
-<div class="sect3">
-<h4 id="threat-common-java-serialization">Java Object Serialization Stream
Protocol</h4>
+<div class="sect1">
+<h2 id="threat-common">Common threat model</h2>
+<div class="sectionbody">
<div class="paragraph">
-<p><a
href="https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html";>Java
Object Serialization Stream Protocol</a> should not be used to deserialize
data from untrusted sources.
-See <a
href="https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data";>the
related OWASP guide</a> for details.</p>
-</div>
-</div>
+<p>All the logging frameworks maintained by Apache Logging Services (<a
href="https://logging.apache.org/log4cxx/index.html";>Log4cxx</a>,
+<a href="https://logging.apache.org/log4j/index.html";>Log4j</a>
+and
+<a href="https://logging.apache.org/log4net/index.html";>Log4net</a>) 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.
+Vulnerability reports that do not adhere to these assumptions will not be
accepted and are <strong>not</strong> eligible for the <a
href="https://yeswehack.com/programs/log4j-bug-bounty-program";>YesWeHack Bug
Bounty Program</a>.</p>
</div>
<div class="sect2">
-<h3 id="threat-log4j">Log4j threat model</h3>
+<h3 id="threat-common-users">User types</h3>
<div class="paragraph">
-<p>Below we share the threat model specific to <a href="/log4j">Log4j</a>.</p>
+<p>Apache Logging Services distinguishes two kinds of users:</p>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-parametrized-logging">Parameterized logging</h4>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Trusted Users</dt>
+<dd>
<div class="paragraph">
-<p>When using a log message containing template parameters like
<code>{}</code>, 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 <code>Message</code> API should be used for logging structured data
combined with a structured layout (e.g., <code>JsonTemplateLayout</code>).
-Format strings should be compile-time constants, and under no circumstances
should format strings be built using user-controlled input data.</p>
-</div>
+<p>Application developers and administrators are considered
<strong>trusted</strong> users.
+They have unrestricted access to all the features of the logging framework and
the environment it is deployed to.</p>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-unstructured-logging">Unstructured logging</h4>
+</dd>
+<dt class="hdlist1">Untrusted Users</dt>
+<dd>
<div class="paragraph">
-<p>When using an unstructured layout such as <code>PatternLayout</code>, 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
<code>%encode{pattern}{CRLF}</code> wrapper pattern converter (which will
encode a carriage return as the string <code>\r</code> and a line feed as the
string <code>\n</code>) or some other <code>%encode</code> option.
-Note that <code>%xEx</code> 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.,
<code>JsonTemplateLayout</code>) is used instead for these situations.
-Note that <code>StrLookup</code> plugins (those referenced by
<code>${…​}</code> templates in configuration files) that contain
user-provided input should not be referenced by layouts.</p>
-</div>
+<p>All the other users are considered untrusted.</p>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-structured-logging">Structured logging</h4>
-<div class="paragraph">
-<p>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 <code>JsonTemplateLayout</code> 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.</p>
+</dd>
+</dl>
</div>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-java-security-manager">Java Security Manager</h4>
+<div class="sect2">
+<h3 id="threat-common-sources">Data sources</h3>
<div class="paragraph">
-<p>Log4j 3 no longer supports running in or using a custom
<code>SecurityManager</code>.
-This Java feature has been deprecated for removal in Java 21.
-Log4j 2 includes partial support for running with a Security Manager.</p>
+<p>Logging systems read data from multiple sources that are controlled by both
trusted and untrusted users:</p>
</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Trusted Sources</dt>
+<dd>
+<div class="ulist">
+<ul>
+<li>
+<p>Log4cxx, Log4j, and Log4net <strong>trust</strong> environment variables,
configuration properties, and configuration files.
+To maintain security, the following responsibilities fall on the deployer:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Ensure that untrusted parties do not have write access to these
resources.</p>
+</li>
+<li>
+<p>Ensure these resources are transmitted only over
<strong>confidential</strong> channels (e.g., HTTPS, secure file systems).</p>
+</li>
+<li>
+<p>Be aware that <strong>non-confidential</strong> channels such as HTTP or
JMX are <strong>disabled by default</strong> to prevent accidental exposure.</p>
+</li>
+<li>
+<p>If configuration files use interpolation features (e.g., (<a
href="https://logging.apache.org/log4j/2.x/manual/lookups.html";>Log4j
Lookups</a>)), ensure that only trusted data sources are used.</p>
+</li>
+<li>
+<p>Pay special attention to values stored in the context map (see <a
href="https://logging.apache.org/log4j/2.x/manual/thread-context.html";>Thread
Context in Log4j</a>).
+Although the context map is only accessible by developers, it has been known
to include user-provided data, such as HTTP headers, which can introduce
risks.</p>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-log-masking">Log masking</h4>
-<div class="paragraph">
-<p>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 <code>Message</code> API for
better control over the output of such data.</p>
-</div>
+</li>
+<li>
+<p>The logging frameworks <strong>trust</strong> that the objects passed to
the log statements can be safely converted to strings:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>These frameworks should not be used to log deserialized data from untrusted
sources.
+See <a
href="https://owasp.org/www-community/vulnerabilities/Deserialization_of_untrusted_data";>the
related OWASP guide</a> for details.</p>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-availability">Availability</h4>
-<div class="paragraph">
-<p>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.</p>
+</li>
+<li>
+<p>If parameterized logging is used, the format string is
<strong>trusted</strong>:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Programmers <strong>should</strong> use compile-time constants as format
strings to prevent attackers from tampering messages.
+See <a
href="https://logging.apache.org/log4j/2.x/manual/api.html#best-practice-concat";>Don’t
use string concatenation</a> for an example.</p>
+</li>
+</ul>
</div>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4j-compressing-logs">Compressing logs</h4>
-<div class="paragraph">
-<p>If log compression is used along with custom encryption where logs contain
user-controlled input, then this can lead to a <a
href="https://en.wikipedia.org/wiki/CRIME";>CRIME attack</a> 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.</p>
+</dd>
+<dt class="hdlist1">Untrusted Sources</dt>
+<dd>
+<div class="ulist">
+<ul>
+<li>
+<p>Log4cxx, Log4j and Log4net <strong>do not</strong> trust log messages.
+No particular input validation for log messages is necessary.</p>
+</li>
+<li>
+<p>They <strong>do not</strong> trust the string representation of log
parameters.</p>
+</li>
+<li>
+<p>The logging frameworks do not trust neither the keys nor the values in the
thread context.</p>
+</li>
+</ul>
</div>
+</dd>
+</dl>
</div>
</div>
<div class="sect2">
-<h3 id="threat-log4net">Log4Net threat model</h3>
+<h3 id="threat-common-threat">Threats</h3>
<div class="paragraph">
-<p>Below we share the threat model specific to <a
href="/log4net">log4net</a>.</p>
+<p>These are the most commonly encountered threats for users of Log4cxx, Log4j
and Log4net:</p>
</div>
-<div class="sect3">
-<h4 id="threat-log4net-parametrized-logging">Parameterized logging</h4>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Log Injection (<a
href="https://cwe.mitre.org/data/definitions/117.html";>CWE-117</a>)</dt>
+<dd>
<div class="paragraph">
-<p>When using a log message containing template parameters like
<code>{0}</code>, 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., <code>XmlLayout</code>) should be used.
-Format strings should be compile-time constants, and under no circumstances
should format strings be built using user-controlled input data.</p>
+<p>Log injection is a common attack vector to hide malicious activity in an
application.
+Regarding this threat:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><strong>Unstructured layouts</strong> such as <a
href="https://logging.apache.org/log4j/2.x/manual/pattern-layout.html";>Pattern
Layout in Log4j</a> do <strong>not</strong> protect users from log injection.
+These layouts are meant for <strong>human</strong> and not computer
consumption.</p>
+</li>
+<li>
+<p>Log4cxx, Log4j and Log4net <strong>must</strong> prevent log injection in
<strong>structured</strong> layouts, such as XML, JSON and RFC 5424.</p>
+</li>
+</ul>
</div>
+</dd>
+<dt class="hdlist1">Supply chain attacks (<a
href="https://cwe.mitre.org/data/definitions/1357.html";>CWE-1357</a>)</dt>
+<dd>
+<div class="ulist">
+<ul>
+<li>
+<p>Apache Logging Services projects <strong>do</strong> check the quality of
our dependencies.</p>
+</li>
+<li>
+<p>Deprecated components such as the
+<a
href="https://logging.apache.org/log4j/2.x/manual/appenders/database.html#CassandraAppender";>Cassandra</a>,
+<a
href="https://logging.apache.org/log4j/2.x/manual/appenders/message-queue.html#KafkaAppender";>Kafka</a>
+and
+<a
href="https://logging.apache.org/log4j/2.x/manual/appenders/database.html#CouchDbProvider";>CouchDB</a>
+appenders are provided for backward compatibility purposes only.
+While we actively check for vulnerabilities in those components, they are
<em>de facto</em> unmaintained, and we discourage their usage in production.</p>
+</li>
+<li>
+<p>All Apache Logging Services are signed with one of the keys in the Logging
Services PMC
+<a href="https://downloads.apache.org/logging/KEYS";>KEYS file</a>.
+We do <strong>not</strong> 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 <a href="download.html">Download page</a></p>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4net-unstructured-logging">Unstructured logging</h4>
+</dd>
+<dt class="hdlist1">Information disclosure (<a
href="https://cwe.mitre.org/data/definitions/200.html";>CWE-200</a>)</dt>
+<dd>
<div class="paragraph">
-<p>When using an unstructured layout such as <code>PatternLayout</code>, 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.,
<code>XmlLayout</code>) is used instead for these situations.</p>
+<p>Since logging frameworks implement information disclosure by design:</p>
</div>
+<div class="ulist">
+<ul>
+<li>
+<p>It is up to the deployer to prevent unauthorized access to log files and to
ensure that the appropriate log levels are configured.</p>
+</li>
+<li>
+<p>It is up to the programmer to document which log levels and markers
<em>might</em> 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.</p>
+</li>
+<li>
+<p><strong>Log masking</strong> techniques are out-of-scope for Log4cxx,
Log4j, and Log4net.
+It is up to the developer to ensure that sensitive data is properly masked
<strong>before</strong> it is passed to the logging implementation.
+For this purpose, <strong>third-party</strong> frameworks like
+<a href="https://github.com/palantir/safe-logging";>Safe-Logging</a>
+should be used.</p>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4net-structured-logging">Structured logging</h4>
+</dd>
+<dt class="hdlist1">Log reliability (e.g. <a
href="https://cwe.mitre.org/data/definitions/778.html";>CVE-778</a>)</dt>
+<dd>
<div class="paragraph">
-<p>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 <code>XmlLayout</code> 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.</p>
+<p>Log4j is designed with <strong>reliability</strong> in mind:</p>
</div>
+<div class="ulist">
+<ul>
+<li>
+<p>By <strong>default</strong>, Log4j <strong>should</strong> deliver log
events to the appropriate resource even during a reconfiguration event or will
log an error.</p>
+</li>
+<li>
+<p>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
+<a
href="https://logging.apache.org/log4j/2.x/manual/appenders/message-queue.html";>message-queue-based
systems</a>
+for example.</p>
+</li>
+<li>
+<p>Log4j provides configuration options that discard log events if the load on
the application is high.
+Using these options invalidates the reliability guarantees.</p>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4net-log-masking">Log masking</h4>
+</dd>
+<dt class="hdlist1">Denial of service (<a
href="https://cwe.mitre.org/data/definitions/779.html";>CVE-779</a>)</dt>
+<dd>
<div class="paragraph">
-<p>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.</p>
+<p>Since our logging frameworks are designed with reliability in mind:</p>
</div>
+<div class="ulist">
+<ul>
+<li>
+<p>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
+<a
href="https://logging.apache.org/log4j/2.x/manual/performance.html";>Performance</a>
+for more information.</p>
+</li>
+<li>
+<p>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.</p>
+</li>
+<li>
+<p>It is up to the developer to ensure that log statements, which are not
enabled, generate minimal overhead.
+See the
+<a
href="https://logging.apache.org/log4j/2.x/manual/api.html#best-practice-concat";>Log4j
API Best Practices</a>, for example.</p>
+</li>
+</ul>
</div>
-<div class="sect3">
-<h4 id="threat-log4net-availability">Availability</h4>
-<div class="paragraph">
-<p>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.</p>
+</dd>
+<dt class="hdlist1">Improper neutralization of Special Elements (<a
href="https://cwe.mitre.org/data/definitions/138.html";>CWE-138</a>)</dt>
+<dd>
+<div class="ulist">
+<ul>
+<li>
+<p>Log4cxx, Log4j, and Log4net <strong>do</strong> allow users to pass
untrusted strings to log statements and thread context, except in the format
string of parameterized logging, as mentioned above.</p>
+</li>
+</ul>
</div>
+</dd>
+</dl>
</div>
</div>
</div>
