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 447e9a71 Automatic Site Publish by Buildbot
447e9a71 is described below
commit 447e9a711f1ab62cf05157e9e766240600b47fbb
Author: buildbot <[email protected]>
AuthorDate: Fri Apr 19 07:57:58 2024 +0000
Automatic Site Publish by Buildbot
---
content/feed.xml | 2 +-
content/security.html | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/content/feed.xml b/content/feed.xml
index ca3f9b4c..295449b5 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-18T09:04:15+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-19T07:57:57+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 35957fc7..efeccdb9 100644
--- a/content/security.html
+++ b/content/security.html
@@ -132,12 +132,109 @@ These instructions can be found in
<code>BUILDING.adoc</code>, <code>BUILDING.md
</td>
<td class="content">
<div class="paragraph">
-<p>The threat model that Log4j 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>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>
</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>
+<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>
+<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.
+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>
+<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 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>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Parameterized logging</dt>
+<dd>
+<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>
+<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>
+</dd>
+<dt class="hdlist1">Structured logging</dt>
+<dd>
+<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>
+<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>
+<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>
+<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>
+<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 class="sect1">
