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 782ff4c Automatic Site Publish by Buildbot
782ff4c is described below
commit 782ff4c98211098f58bd98590a5d047d229d1b5e
Author: buildbot <[email protected]>
AuthorDate: Thu Dec 23 13:58:46 2021 +0000
Automatic Site Publish by Buildbot
---
output/feeds/all.atom.xml | 8 ++++----
output/feeds/solr/security.atom.xml | 8 ++++----
output/news.html | 8 ++++----
output/security.html | 8 ++++----
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/output/feeds/all.atom.xml b/output/feeds/all.atom.xml
index db44f70..87f074b 100644
--- a/output/feeds/all.atom.xml
+++ b/output/feeds/all.atom.xml
@@ -59,10 +59,7 @@ 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 <strong>CVE-2021-45046</strong> and
<strong>CVE-2021-45105</strong>, 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
-and injected into log files with "<code>%X</code>". Passing system
property <code>log4j2.formatMsgNoLookups=true</code> (as described
below)
-is suitable to mitigate.</p>
+<p>Solr is <em>not</em> vulnerable to the followup
<strong>CVE-2021-45046</strong> and
<strong>CVE-2021-45105</strong>. A listing of these and other CVEs
with some justifications are listed in Solr's wiki:
https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
@@ -75,6 +72,9 @@ Any of the following are enough to prevent this vulnerability
for Solr servers:&
<code>set SOLR_OPTS=%SOLR_OPTS%
-Dlog4j2.formatMsgNoLookups=true</code></li>
<li>Follow any of the other mitgations listed at <a
href="https://logging.apache.org/log4j/2.x/security.html">https://logging.apache.org/log4j/2.x/security.html</a></li>
</ul>
+<p>The Log4J security page refers to setting
<code>log4j2.formatMsgNoLookups=true</code> as a "discredited"
mitigation. In reality, it depends.
+We've looked at the root cause and audited the code paths that lead to the
vulnerability, and we feel confident in this mitigation being sufficient for
Solr.
+See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz">https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz</a>
for discussion.</p>
<p><strong>References:</strong>
<a
href="https://logging.apache.org/log4j/2.x/security.html">https://logging.apache.org/log4j/2.x/security.html</a></p></content><category
term="solr/security"></category></entry><entry><title>Apache Solr Operator™
v0.5.0 available</title><link
href="/apache-solr-operatortm-v050-available.html"
rel="alternate"></link><published>2021-11-16T00:00:00+00:00</published><updated>2021-11-16T00:00:00+00:00</updated><author><name>Solr
Developers</name></author><id>tag:None,2021- [...]
<p>The Apache Solr Operator is a safe and easy way of managing a Solr
ecosystem in Kubernetes.</p>
diff --git a/output/feeds/solr/security.atom.xml
b/output/feeds/solr/security.atom.xml
index fb5484d..987daa7 100644
--- a/output/feeds/solr/security.atom.xml
+++ b/output/feeds/solr/security.atom.xml
@@ -33,10 +33,7 @@ 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 <strong>CVE-2021-45046</strong> and
<strong>CVE-2021-45105</strong>, 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
-and injected into log files with "<code>%X</code>". Passing system
property <code>log4j2.formatMsgNoLookups=true</code> (as described
below)
-is suitable to mitigate.</p>
+<p>Solr is <em>not</em> vulnerable to the followup
<strong>CVE-2021-45046</strong> and
<strong>CVE-2021-45105</strong>. A listing of these and other CVEs
with some justifications are listed in Solr's wiki:
https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
@@ -49,6 +46,9 @@ Any of the following are enough to prevent this vulnerability
for Solr servers:&
<code>set SOLR_OPTS=%SOLR_OPTS%
-Dlog4j2.formatMsgNoLookups=true</code></li>
<li>Follow any of the other mitgations listed at <a
href="https://logging.apache.org/log4j/2.x/security.html">https://logging.apache.org/log4j/2.x/security.html</a></li>
</ul>
+<p>The Log4J security page refers to setting
<code>log4j2.formatMsgNoLookups=true</code> as a "discredited"
mitigation. In reality, it depends.
+We've looked at the root cause and audited the code paths that lead to the
vulnerability, and we feel confident in this mitigation being sufficient for
Solr.
+See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz">https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz</a>
for discussion.</p>
<p><strong>References:</strong>
<a
href="https://logging.apache.org/log4j/2.x/security.html">https://logging.apache.org/log4j/2.x/security.html</a></p></content><category
term="solr/security"></category></entry><entry><title>CVE-2021-27905: SSRF
vulnerability with the Replication handler</title><link
href="/cve-2021-27905-ssrf-vulnerability-with-the-replication-handler.html"
rel="alternate"></link><published>2021-04-12T00:00:00+00:00</published><updated>2021-04-12T00:00:00+00:00</updated><author><name
[...]
High</p>
diff --git a/output/news.html b/output/news.html
index 85106d7..dd7e9b8 100644
--- a/output/news.html
+++ b/output/news.html
@@ -192,10 +192,7 @@ 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
<strong>CVE-2021-45046</strong> and <strong>CVE-2021-45105</strong>, 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
-and injected into log files with "<code>%X</code>". Passing system property
<code>log4j2.formatMsgNoLookups=true</code> (as described below)
-is suitable to mitigate.</p>
+<p>Solr is <em>not</em> vulnerable to the followup
<strong>CVE-2021-45046</strong> and <strong>CVE-2021-45105</strong>. A listing
of these and other CVEs with some justifications are listed in Solr's wiki:
https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
@@ -208,6 +205,9 @@ Any of the following are enough to prevent this
vulnerability for Solr servers:<
<code>set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true</code></li>
<li>Follow any of the other mitgations listed at <a
href="https://logging.apache.org/log4j/2.x/security.html";>https://logging.apache.org/log4j/2.x/security.html</a></li>
</ul>
+<p>The Log4J security page refers to setting
<code>log4j2.formatMsgNoLookups=true</code> as a "discredited" mitigation. In
reality, it depends.
+We've looked at the root cause and audited the code paths that lead to the
vulnerability, and we feel confident in this mitigation being sufficient for
Solr.
+See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz";>https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz</a>
for discussion.</p>
<p><strong>References:</strong>
<a
href="https://logging.apache.org/log4j/2.x/security.html";>https://logging.apache.org/log4j/2.x/security.html</a></p>
<h2 id="apache-solrtm-8110-available">16 November 2021, Apache Solr™ 8.11.0
available
diff --git a/output/security.html b/output/security.html
index 610d796..6cc277a 100644
--- a/output/security.html
+++ b/output/security.html
@@ -248,10 +248,7 @@ 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
<strong>CVE-2021-45046</strong> and <strong>CVE-2021-45105</strong>, 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
-and injected into log files with "<code>%X</code>". Passing system property
<code>log4j2.formatMsgNoLookups=true</code> (as described below)
-is suitable to mitigate.</p>
+<p>Solr is <em>not</em> vulnerable to the followup
<strong>CVE-2021-45046</strong> and <strong>CVE-2021-45105</strong>. A listing
of these and other CVEs with some justifications are listed in Solr's wiki:
https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools</p>
<p><strong>Mitigation:</strong>
Any of the following are enough to prevent this vulnerability for Solr
servers:</p>
<ul>
@@ -264,6 +261,9 @@ Any of the following are enough to prevent this
vulnerability for Solr servers:<
<code>set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true</code></li>
<li>Follow any of the other mitgations listed at <a
href="https://logging.apache.org/log4j/2.x/security.html";>https://logging.apache.org/log4j/2.x/security.html</a></li>
</ul>
+<p>The Log4J security page refers to setting
<code>log4j2.formatMsgNoLookups=true</code> as a "discredited" mitigation. In
reality, it depends.
+We've looked at the root cause and audited the code paths that lead to the
vulnerability, and we feel confident in this mitigation being sufficient for
Solr.
+See <a
href="https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz";>https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz</a>
for discussion.</p>
<p><strong>References:</strong>
<a
href="https://logging.apache.org/log4j/2.x/security.html";>https://logging.apache.org/log4j/2.x/security.html</a></p>
<hr/>
