This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/solr-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new e7f5f41 Automatic Site Publish by Buildbot
e7f5f41 is described below
commit e7f5f412823802c1c8c3ee52469fcad627805845
Author: buildbot <[email protected]>
AuthorDate: Wed Dec 15 20:25:28 2021 +0000
Automatic Site Publish by Buildbot
---
output/feeds/all.atom.xml | 5 ++++-
output/feeds/solr/security.atom.xml | 5 ++++-
output/news.html | 5 ++++-
output/security.html | 5 ++++-
4 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/output/feeds/all.atom.xml b/output/feeds/all.atom.xml
index 458a7a0..ce1df9d 100644
--- a/output/feeds/all.atom.xml
+++ b/output/feeds/all.atom.xml
@@ -12,10 +12,13 @@ Critical</p>
Apache Solr releases prior to 8.11.1 were using a bundled version of the
Apache Log4J library vulnerable to RCE. For full impact and additional detail
consult the Log4J security page.</p>
<p>Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7
through 7.3) use Log4J 1.2.17 which may be vulnerable for installations using
non-default logging configurations that include the JMS Appender, see <a
href="https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126">https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126</a>
for discussion.</p>
<p>Solr's Prometheus Exporter uses Log4J as well but it does not log
user input or data, so we don't see a risk there.</p>
+<p>Apache Solr releases are <em>not</em> vulnerable to the
followup CVE-2021-45046, because the MDC patterns used by Solr are for the
+collection, shard, replica, core and node names, and a potential trace id,
which are all sanitized. Passing system property
+<code>log4j2.formatMsgNoLookups=true</code> (as described below)
is suitable to mitigate.</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
-<li>Upgrade to <code>Solr 8.11.1</code> or greater (when
available), which will include an updated version of the Log4J
dependency.</li>
+<li>Upgrade to <code>Solr 8.11.1</code> or greater (when
available), which will include an updated version (<code>&gt;=
2.16.0</code>) of the Log4J dependency.</li>
<li>If you are using Solr's official docker image, it has already been
mitigated in all versions listed as supported on Docker Hub: <a
href="https://hub.docker.com/_/solr">https://hub.docker.com/_/solr</a>.
You may need to re-pull the image.</li>
<li>Manually update the version of Log4J on your runtime classpath and
restart your Solr application.</li>
<li>(Linux/MacOS) Edit your <code>solr.in.sh</code> file to
include:
diff --git a/output/feeds/solr/security.atom.xml
b/output/feeds/solr/security.atom.xml
index 2fcccd5..1f12407 100644
--- a/output/feeds/solr/security.atom.xml
+++ b/output/feeds/solr/security.atom.xml
@@ -12,10 +12,13 @@ Critical</p>
Apache Solr releases prior to 8.11.1 were using a bundled version of the
Apache Log4J library vulnerable to RCE. For full impact and additional detail
consult the Log4J security page.</p>
<p>Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7
through 7.3) use Log4J 1.2.17 which may be vulnerable for installations using
non-default logging configurations that include the JMS Appender, see <a
href="https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126">https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126</a>
for discussion.</p>
<p>Solr's Prometheus Exporter uses Log4J as well but it does not log
user input or data, so we don't see a risk there.</p>
+<p>Apache Solr releases are <em>not</em> vulnerable to the
followup CVE-2021-45046, because the MDC patterns used by Solr are for the
+collection, shard, replica, core and node names, and a potential trace id,
which are all sanitized. Passing system property
+<code>log4j2.formatMsgNoLookups=true</code> (as described below)
is suitable to mitigate.</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
-<li>Upgrade to <code>Solr 8.11.1</code> or greater (when
available), which will include an updated version of the Log4J
dependency.</li>
+<li>Upgrade to <code>Solr 8.11.1</code> or greater (when
available), which will include an updated version (<code>&gt;=
2.16.0</code>) of the Log4J dependency.</li>
<li>If you are using Solr's official docker image, it has already been
mitigated in all versions listed as supported on Docker Hub: <a
href="https://hub.docker.com/_/solr">https://hub.docker.com/_/solr</a>.
You may need to re-pull the image.</li>
<li>Manually update the version of Log4J on your runtime classpath and
restart your Solr application.</li>
<li>(Linux/MacOS) Edit your <code>solr.in.sh</code> file to
include:
diff --git a/output/news.html b/output/news.html
index b24b424..c85d5d4 100644
--- a/output/news.html
+++ b/output/news.html
@@ -143,10 +143,13 @@ Critical</p>
Apache Solr releases prior to 8.11.1 were using a bundled version of the
Apache Log4J library vulnerable to RCE. For full impact and additional detail
consult the Log4J security page.</p>
<p>Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 through
7.3) use Log4J 1.2.17 which may be vulnerable for installations using
non-default logging configurations that include the JMS Appender, see <a
href="https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126";>https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126</a>
for discussion.</p>
<p>Solr's Prometheus Exporter uses Log4J as well but it does not log user
input or data, so we don't see a risk there.</p>
+<p>Apache Solr releases are <em>not</em> vulnerable to the followup
CVE-2021-45046, because the MDC patterns used by Solr are for the
+collection, shard, replica, core and node names, and a potential trace id,
which are all sanitized. Passing system property
+<code>log4j2.formatMsgNoLookups=true</code> (as described below) is suitable
to mitigate.</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
-<li>Upgrade to <code>Solr 8.11.1</code> or greater (when available), which
will include an updated version of the Log4J dependency.</li>
+<li>Upgrade to <code>Solr 8.11.1</code> or greater (when available), which
will include an updated version (<code>>= 2.16.0</code>) of the Log4J
dependency.</li>
<li>If you are using Solr's official docker image, it has already been
mitigated in all versions listed as supported on Docker Hub: <a
href="https://hub.docker.com/_/solr";>https://hub.docker.com/_/solr</a>. You
may need to re-pull the image.</li>
<li>Manually update the version of Log4J on your runtime classpath and restart
your Solr application.</li>
<li>(Linux/MacOS) Edit your <code>solr.in.sh</code> file to include:
diff --git a/output/security.html b/output/security.html
index 2ec4f82..e750fe0 100644
--- a/output/security.html
+++ b/output/security.html
@@ -227,10 +227,13 @@ Critical</p>
Apache Solr releases prior to 8.11.1 were using a bundled version of the
Apache Log4J library vulnerable to RCE. For full impact and additional detail
consult the Log4J security page.</p>
<p>Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 through
7.3) use Log4J 1.2.17 which may be vulnerable for installations using
non-default logging configurations that include the JMS Appender, see <a
href="https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126";>https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126</a>
for discussion.</p>
<p>Solr's Prometheus Exporter uses Log4J as well but it does not log user
input or data, so we don't see a risk there.</p>
+<p>Apache Solr releases are <em>not</em> vulnerable to the followup
CVE-2021-45046, because the MDC patterns used by Solr are for the
+collection, shard, replica, core and node names, and a potential trace id,
which are all sanitized. Passing system property
+<code>log4j2.formatMsgNoLookups=true</code> (as described below) is suitable
to mitigate.</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
-<li>Upgrade to <code>Solr 8.11.1</code> or greater (when available), which
will include an updated version of the Log4J dependency.</li>
+<li>Upgrade to <code>Solr 8.11.1</code> or greater (when available), which
will include an updated version (<code>>= 2.16.0</code>) of the Log4J
dependency.</li>
<li>If you are using Solr's official docker image, it has already been
mitigated in all versions listed as supported on Docker Hub: <a
href="https://hub.docker.com/_/solr";>https://hub.docker.com/_/solr</a>. You
may need to re-pull the image.</li>
<li>Manually update the version of Log4J on your runtime classpath and restart
your Solr application.</li>
<li>(Linux/MacOS) Edit your <code>solr.in.sh</code> file to include:
