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 0909e9d4 Automatic Site Publish by Buildbot
0909e9d4 is described below
commit 0909e9d4a7577bff383671fdd8e239e9239e3899
Author: buildbot <[email protected]>
AuthorDate: Tue Apr 23 08:38:24 2024 +0000
Automatic Site Publish by Buildbot
---
content/feed.xml | 2 +-
content/security.html | 111 +++++++++++++++++++++++++++-----------------------
2 files changed, 61 insertions(+), 52 deletions(-)
diff --git a/content/feed.xml b/content/feed.xml
index 94036594..1e243dcd 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.2.2">Jekyll</generator><link href="/feed.xml" rel="self"
type="application/atom+xml" /><link href="/" rel="alternate" type="text/html"
/><updated>2024-04-21T19:55:47+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.2.2">Jekyll</generator><link href="/feed.xml" rel="self"
type="application/atom+xml" /><link href="/" rel="alternate" type="text/html"
/><updated>2024-04-23T08:38:23+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>Today, December 17, 2023 marks a significant milestone for the Apache
Logging Services project,
as we celebrate 20 years since the inception of Log4j 1.
diff --git a/content/security.html b/content/security.html
index efeccdb9..ee17e2cd 100644
--- a/content/security.html
+++ b/content/security.html
@@ -124,33 +124,37 @@ These instructions can be found in
<code>BUILDING.adoc</code>, <code>BUILDING.md
<div class="paragraph">
<p>If you have encountered an unlisted security vulnerability or other
unexpected behaviour that has a security impact, or if the descriptions here
are incomplete, please report them <strong>privately</strong> to <a
href="mailto:[email protected]";>the Logging Services Security
Team</a>.</p>
</div>
-<div class="admonitionblock warning">
+<div class="admonitionblock important">
<table>
<tr>
<td class="icon">
-<div class="title">Warning</div>
+<div class="title">Important</div>
</td>
<td class="content">
<div class="paragraph">
-<p>The threat model that Logging Services uses considers configuration files
as safe input controlled by the programmer; <strong>potential vulnerabilities
that require the ability to modify a configuration are not considered
vulnerabilities</strong> as the required access to do so implies the attacker
can execute arbitrary code.</p>
+<p>We urge you to <strong>carefully read the threat model</strong> detailed in
following sections before submitting a report.
+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.</p>
</div>
</td>
</tr>
</table>
</div>
-<details>
-<summary class="title">Common threat model</summary>
-<div class="content">
-<div class="dlist">
-<dl>
-<dt class="hdlist1">Code signing</dt>
-<dd>
+<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>
-</dd>
-<dt class="hdlist1">Configuration sources</dt>
-<dd>
+</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.
@@ -158,37 +162,34 @@ This remote location must be kept safe from unauthorized
modifications.
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>
-</dd>
-<dt class="hdlist1">Java Object Serialization Stream Protocol</dt>
-<dd>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-common-java-serialization">Java Object Serialization Stream
Protocol</h4>
+<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>
-</dd>
-</dl>
</div>
</div>
-</details>
-<details>
-<summary class="title">Log4j threat model</summary>
-<div class="content">
+</div>
+<div class="sect2">
+<h3 id="threat-log4j">Log4j threat model</h3>
<div class="paragraph">
-<p>Configuration inputs and the classpath are expected to be controlled by the
programmer.
-Configurations have the ability to execute arbitrary code.
-While specific plugins (such as a JNDI lookup) may use constraint validators
or conditionals to require additional settings to opt in to functionality, this
is not universally required by custom plugins.
-Specific security considerations involved in our threat model are detailed
below.</p>
+<p>Below we share the threat model specific to <a href="/log4j">Log4j</a>.</p>
</div>
-<div class="dlist">
-<dl>
-<dt class="hdlist1">Parameterized logging</dt>
-<dd>
+<div class="sect3">
+<h4 id="threat-log4j-parametrized-logging">Parameterized logging</h4>
+<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>
-</dd>
-<dt class="hdlist1">Unstructured logging</dt>
-<dd>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-log4j-unstructured-logging">Unstructured logging</h4>
+<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.
@@ -197,44 +198,52 @@ Similarly, other encoding options are available for other
formats, but pattern l
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>
-</dd>
-<dt class="hdlist1">Structured logging</dt>
-<dd>
+</div>
+</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>
-<dt class="hdlist1">Java Security Manager</dt>
-<dd>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-log4j-java-security-manager">Java Security Manager</h4>
+<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>
-</dd>
-<dt class="hdlist1">Log masking</dt>
-<dd>
+</div>
+</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>
-</dd>
-<dt class="hdlist1">Availability</dt>
-<dd>
+</div>
+</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>
-</dd>
-<dt class="hdlist1">Compressing logs</dt>
-<dd>
+</div>
+</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>
-</dl>
</div>
</div>
-</details>
+</div>
</div>
</div>
<div class="sect1">
