| <?xml version="1.0" encoding="utf-8"?> |
| <feed xmlns="http://www.w3.org/2005/Atom"><title>Apache Solr - solr/security</title><link href="/" rel="alternate"></link><link href="/feeds/solr/security.atom.xml" rel="self"></link><id>/</id><updated>2024-04-12T00:00:00+00:00</updated><subtitle></subtitle><subtitle></subtitle><entry><title>CVE-2024-31391: Solr-Operator liveness and readiness probes may leak basic auth credentials</title><link href="/cve-2024-31391-solr-operator-liveness-and-readiness-probes-may-leak-basic-auth-credentials.html" rel="alternate"></link><published>2024-04-12T00:00:00+00:00</published><updated>2024-04-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-04-12:/cve-2024-31391-solr-operator-liveness-and-readiness-probes-may-leak-basic-auth-credentials.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr Operator 0.3.0 to 0.8.0</p> |
| <p><strong>Description:</strong> |
| Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.</p> |
| <p>The Solr sked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr Operator 0.3.0 to 0.8.0</p> |
| <p><strong>Description:</strong> |
| Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.</p> |
| <p>The Solr sked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr. |
| One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic. |
| By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well. |
| Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account.</p> |
| <p>Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the <code>.solrOptions.security.authenticationType=basic</code> option, and (2) required authentication be used on probes by setting <code>.solrOptions.security.probesRequireAuth=true</code>.</p> |
| <p><strong>Mitigation:</strong> |
| Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests. Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting <code>.solrOptions.security.probesRequireAuth=false</code>.</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-17216">SOLR-17216</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-31391">CVE-2024-31391</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2023-50291: Apache Solr can leak certain passwords due to System Property redaction logic inconsistencies</title><link href="/cve-2023-50291-apache-solr-can-leak-certain-passwords-due-to-system-property-redaction-logic-inconsistencies.html" rel="alternate"></link><published>2024-02-08T00:00:00+00:00</published><updated>2024-02-08T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-02-08:/cve-2023-50291-apache-solr-can-leak-certain-passwords-due-to-system-property-redaction-logic-inconsistencies.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.3.0</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Insufficiently Protected Credentials vulnerability in Apache Solr.</p> |
| <p>This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3 …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.3.0</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Insufficiently Protected Credentials vulnerability in Apache Solr.</p> |
| <p>This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0. |
| One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name. |
| There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint. |
| This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI.</p> |
| <p>This /admin/info/properties endpoint is protected under the "config-read" permission. |
| Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission. |
| Users are recommended to upgrade to version 9.3.0 or 8.11.3, which fixes the issue. |
| A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps". |
| By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password".</p> |
| <p>Users who cannot upgrade can also use the following Java system property to fix the issue:<br> |
| <code>-Dsolr.redaction.system.pattern=".*(password|secret|basicauth).*"</code></p> |
| <p><strong>Mitigation:</strong><br> |
| Users are recommended to upgrade to version 8.11.3, 9.3.0 or later, which has consistent systemProperty redaction logic.</p> |
| <p><strong>Credit:</strong> |
| Michael Taggart (reporter)</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16809">SOLR-16809</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50291">CVE-2023-50291</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2023-50292: Apache Solr Schema Designer blindly "trusts" all configsets, possibly leading to RCE by unauthenticated users</title><link href="/cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users.html" rel="alternate"></link><published>2024-02-08T00:00:00+00:00</published><updated>2024-02-08T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-02-08:/cve-2023-50292-apache-solr-schema-designer-blindly-trusts-all-configsets-possibly-leading-to-rce-by-unauthenticated-users.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.3.0</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr.</p> |
| <p>This issue affects Apache Solr: from 8.10.0 through 8 …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.3.0</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr.</p> |
| <p>This issue affects Apache Solr: from 8.10.0 through 8.11.2, from 9.0.0 before 9.3.0.</p> |
| <p>The Schema Designer was introduced to allow users to more easily configure and test new Schemas and configSets. |
| However, when the feature was created, the "trust" (authentication) of these configSets was not considered. |
| External library loading is only available to configSets that are "trusted" (created by authenticated users), thus non-authenticated users are unable to perform Remote Code Execution. |
| Since the Schema Designer loaded configSets without taking their "trust" into account, configSets that were created by unauthenticated users were allowed to load external libraries when used in the Schema Designer.</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are recommended to upgrade to version 8.11.3, 9.3.0 or later.</p> |
| <p><strong>Credit:</strong> |
| Skay (reporter)</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16777">SOLR-16777</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50292">CVE-2023-50292</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2023-50298: Apache Solr can expose ZooKeeper credentials via Streaming Expressions</title><link href="/cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions.html" rel="alternate"></link><published>2024-02-08T00:00:00+00:00</published><updated>2024-02-08T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-02-08:/cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Low</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.4.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9 …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Low</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.4.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.</p> |
| <p>Solr Streaming Expressions allows users to extract data from other Solr Clouds, using a "zkHost" parameter. |
| When original SolrCloud is setup to use ZooKeeper credentials and ACLs, they will be sent to whatever "zkHost" the user provides. |
| An attacker could setup a server to mock ZooKeeper, that accepts ZooKeeper requests with credentials and ACLs and extracts the sensitive information, |
| then send a streaming expression using the mock server's address in "zkHost". |
| Streaming Expressions are exposed via the "/streaming" handler, with "read" permissions.</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue. |
| From these versions on, only zkHost values that have the same server address (regardless of chroot), will use the given ZooKeeper credentials and ACLs when connecting.</p> |
| <p><strong>Credit:</strong> |
| Qing Xu (reporter)</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-17098">SOLR-17098</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50298">CVE-2023-50298</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2023-50386: Apache Solr: Backup/Restore APIs allow for deployment of executables in malicious ConfigSets</title><link href="/cve-2023-50386-apache-solr-backuprestore-apis-allow-for-deployment-of-executables-in-malicious-configsets.html" rel="alternate"></link><published>2024-02-08T00:00:00+00:00</published><updated>2024-02-08T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-02-08:/cve-2023-50386-apache-solr-backuprestore-apis-allow-for-deployment-of-executables-in-malicious-configsets.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.4.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Apache Solr 6.0.0 through 8.11.2</li> |
| <li>Apache Solr 9.0.0 before 9.4.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.</p> |
| <p>In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API. |
| When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups). |
| If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted.</p> |
| <p>When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries.</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue. |
| In these versions, the following protections have been added:</p> |
| <ul> |
| <li>Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader.</li> |
| <li>The Backup API restricts saving backups to directories that are used in the ClassLoader.</li> |
| </ul> |
| <p><strong>Credit:</strong> |
| L3yx (reporter)</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16949">SOLR-16949</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50386">CVE-2023-50386</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2023-50290: Apache Solr allows read access to host environment variables</title><link href="/cve-2023-50290-apache-solr-allows-read-access-to-host-environment-variables.html" rel="alternate"></link><published>2024-01-12T00:00:00+00:00</published><updated>2024-01-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2024-01-12:/cve-2023-50290-apache-solr-allows-read-access-to-host-environment-variables.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Important</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr 9.0 to 9.2.1</p> |
| <p><strong>Description:</strong><br> |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr. |
| The Solr Metrics API publishes all unprotected environment variables available to each Apache Solr instance. |
| Users are able to specify which environment variables to hide, however …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Important</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr 9.0 to 9.2.1</p> |
| <p><strong>Description:</strong><br> |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr. |
| The Solr Metrics API publishes all unprotected environment variables available to each Apache Solr instance. |
| Users are able to specify which environment variables to hide, however, the default list is designed to work for known secret Java system properties. |
| Environment variables cannot be strictly defined in Solr, like Java system properties can be, and may be set for the entire host, unlike Java system properties which are set per-Java-process.</p> |
| <p>The Solr Metrics API is protected by the "metrics-read" permission. |
| Therefore, Solr Clouds with Authorization setup will only be vulnerable via users with the "metrics-read" permission.</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are recommended to upgrade to version 9.3.0 or later, in which environment variables are not published via the Metrics API.</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16808">SOLR-15233</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-50290">CVE-2023-50290</a></p></content><category term="solr/security"></category></entry><entry><title>Apache Solr is vulnerable to CVE-2022-39135 via /sql handler</title><link href="/apache-solr-is-vulnerable-to-cve-2022-39135-via-sql-handler.html" rel="alternate"></link><published>2022-11-20T00:00:00+00:00</published><updated>2022-11-20T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2022-11-20:/apache-solr-is-vulnerable-to-cve-2022-39135-via-sql-handler.html</id><summary type="html"><p><strong>Versions Affected:</strong><br> |
| Solr 6.5 to 8.11.2 |
| Solr 9.0</p> |
| <p><strong>Description:</strong><br> |
| Apache Calcite has a vulnerability, CVE-2022-39135, that is exploitable in Apache Solr in SolrCloud mode. If an untrusted user can supply SQL queries to Solr’s “/sql” handler (even indirectly via proxies / other apps), then the user …</p></summary><content type="html"><p><strong>Versions Affected:</strong><br> |
| Solr 6.5 to 8.11.2 |
| Solr 9.0</p> |
| <p><strong>Description:</strong><br> |
| Apache Calcite has a vulnerability, CVE-2022-39135, that is exploitable in Apache Solr in SolrCloud mode. If an untrusted user can supply SQL queries to Solr’s “/sql” handler (even indirectly via proxies / other apps), then the user could perform an XML External Entity (XXE) attack. This might have been exposed by some deployers of Solr in order for internal analysts to use JDBC based tooling, but would have unlikely been granted to wider audiences.</p> |
| <p><strong>Impact:</strong><br> |
| An XXE attack may lead to the disclosure of confidential data, denial of service, server side request forgery (SSRF), port scanning from the Solr node, and other system impacts.</p> |
| <p><strong>Mitigation:</strong><br> |
| Most Solr installations don’t make use of the SQL functionality. For such users, the standard Solr security advice of using a firewall should be adequate. Nonetheless, the functionality can be disabled. As of Solr 9, it has been modularized and thus became opt-in, so nothing is needed for Solr 9 users that don’t use it. Users <em>not</em> using SolrCloud can’t use the functionality at all. For other users that wish to disable it, you must register a request handler that masks the underlying functionality in solrconfig.xml like so:</p> |
| <div class="codehilite"><pre><span></span><code><span class="err"> &lt;requestHandler name=&quot;/sql&quot; class=&quot;solr.NotFoundRequestHandler&quot;/&gt;</span> |
| </code></pre></div> |
| |
| <p>Users needing this SQL functionality are forced to upgrade to Solr 9.1. If Solr 8.11.3 is released, then it will be an option as well. Simply replacing Calcite and other JAR files may mostly work but could fail depending on the particulars of the query. Users interested in this or in patching their own versions of Solr should examine SOLR-16421 for a source patch.</p> |
| <p><strong>Credit:</strong><br> |
| Andreas Hubold at CoreMedia GmbH</p> |
| <p><strong>References:</strong><br> |
| JIRA - <a href="https://issues.apache.org/jira/browse/SOLR-16421">SOLR-16421</a><br> |
| CVE - <a href="https://nvd.nist.gov/vuln/detail/CVE-2022-39135">CVE-2022-39135</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2021-44548: Apache Solr information disclosure vulnerability through DataImportHandler</title><link href="/cve-2021-44548-apache-solr-information-disclosure-vulnerability-through-dataimporthandler.html" rel="alternate"></link><published>2021-12-18T00:00:00+00:00</published><updated>2021-12-18T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2021-12-18:/cve-2021-44548-apache-solr-information-disclosure-vulnerability-through-dataimporthandler.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong><br> |
| All versions prior to 8.11.1. Affected platforms: Windows.</p> |
| <p><strong>Description:</strong><br> |
| An Improper Input Validation vulnerability in DataImportHandler of Apache Solr allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Moderate</p> |
| <p><strong>Versions Affected:</strong><br> |
| All versions prior to 8.11.1. Affected platforms: Windows.</p> |
| <p><strong>Description:</strong><br> |
| An Improper Input Validation vulnerability in DataImportHandler of Apache Solr allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on the network. If the attacker has wider access to the network, this may lead to SMB attacks, which may result in:</p> |
| <ul> |
| <li>The exfiltration of sensitive data such as OS user hashes (NTLM/LM hashes),</li> |
| <li>In case of misconfigured systems, SMB Relay Attacks which can lead to user impersonation on SMB Shares or, in a worse-case scenario, Remote Code Execution</li> |
| </ul> |
| <p>This issue affects all Apache Solr versions prior to 8.11.1. This issue only affects Windows.</p> |
| <p><strong>Mitigation:</strong><br> |
| Upgrade to Solr 8.11.1, and/or ensure only trusted clients can make requests to Solr's DataImport handler.</p> |
| <p><strong>Credit:</strong><br> |
| Apache Solr would like to thank LaiHan of Nsfocus security team for reporting the issue</p> |
| <p><strong>References:</strong><br> |
| Jira issue <a href="https://issues.apache.org/jira/browse/SOLR-15826">SOLR-15826</a></p></content><category term="solr/security"></category></entry><entry><title>Apache Solr affected by Apache Log4J CVE-2021-44228</title><link href="/apache-solr-affected-by-apache-log4j-cve-2021-44228.html" rel="alternate"></link><published>2021-12-10T00:00:00+00:00</published><updated>2021-12-10T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2021-12-10:/apache-solr-affected-by-apache-log4j-cve-2021-44228.html</id><summary type="html"><p><strong>Severity:</strong> |
| Critical</p> |
| <p><strong>Versions Affected:</strong> |
| 7.4.0 to 7.7.3, 8.0.0 to 8.11.0</p> |
| <p><strong>Description:</strong> |
| 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 …</p></summary><content type="html"><p><strong>Severity:</strong> |
| Critical</p> |
| <p><strong>Versions Affected:</strong> |
| 7.4.0 to 7.7.3, 8.0.0 to 8.11.0</p> |
| <p><strong>Description:</strong> |
| 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>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: <a href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools">https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools</a></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 (<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: |
| <code>SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"</code></li> |
| <li>(Windows) Edit your <code>solr.in.cmd</code> file to include: |
| <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>Solr Developers</name></author><id>tag:None,2021-04-12:/cve-2021-27905-ssrf-vulnerability-with-the-replication-handler.html</id><summary type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.8.1</p> |
| <p><strong>Description:</strong> |
| The ReplicationHandler (normally registered at "/replication" under a Solr core) has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index …</p></summary><content type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.8.1</p> |
| <p><strong>Description:</strong> |
| The ReplicationHandler (normally registered at "/replication" under a Solr core) has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. |
| To prevent a SSRF vulnerability, Solr ought to check these parameters against a similar configuration it uses for the "shards" parameter. Prior to this bug getting fixed, it did not.</p> |
| <p><strong>Mitigation:</strong> |
| Any of the following are enough to prevent this vulnerability:</p> |
| <ul> |
| <li>Upgrade to <code>Solr 8.8.2</code> or greater.</li> |
| <li>If upgrading is not an option, consider applying the patch in <a href="https://issues.apache.org/jira/browse/SOLR-15217">SOLR-15217</a></li> |
| <li>Ensure that any access to the replication handler is purely internal to Solr. Typically, it's only accessed externally for diagnostic/informational purposes.</li> |
| </ul> |
| <p><strong>Credit:</strong> |
| Reported by Caolinhong(Skay) from QI-ANXIN Cert (QI-ANXIN Technology Group Inc.)</p> |
| <p><strong>References:</strong> |
| <a href="https://issues.apache.org/jira/browse/SOLR-15217">SOLR-15217</a>: CVE-2021-27905: SSRF vulnerability with the Replication handler</p></content><category term="solr/security"></category></entry><entry><title>CVE-2021-29262: Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings</title><link href="/cve-2021-29262-misapplied-zookeeper-acls-can-result-in-leakage-of-configured-authentication-and-authorization-settings.html" rel="alternate"></link><published>2021-04-12T00:00:00+00:00</published><updated>2021-04-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2021-04-12:/cve-2021-29262-misapplied-zookeeper-acls-can-result-in-leakage-of-configured-authentication-and-authorization-settings.html</id><summary type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.8.1</p> |
| <p><strong>Description:</strong> |
| When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr …</p></summary><content type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.8.1</p> |
| <p><strong>Description:</strong> |
| When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be readable. |
| Additionally, with any ZkACLProvider, if the security.json is already present, Solr will not automatically update the ACLs.</p> |
| <p><strong>Mitigation:</strong> |
| Any of the following are enough to prevent this vulnerability:</p> |
| <ul> |
| <li>Manually set appropriate ACLs on /security.json znode.</li> |
| <li>Upgrade to <code>Solr 8.8.2</code> or greater.</li> |
| <li>If upgrading is not an option, consider applying the patch in <a href="https://issues.apache.org/jira/browse/SOLR-15249">SOLR-15249</a></li> |
| <li>Ensure that any access to zookeeper is only by trusted application.</li> |
| </ul> |
| <p><strong>Credit:</strong> |
| Timothy Potter and Mike Drob, Apple Cloud Services</p> |
| <p><strong>References:</strong> |
| <a href="https://issues.apache.org/jira/browse/SOLR-15249">SOLR-15249</a>: CVE-2021-29262: Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings</p></content><category term="solr/security"></category></entry><entry><title>CVE-2021-29943: Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections</title><link href="/cve-2021-29943-apache-solr-unprivileged-users-may-be-able-to-perform-unauthorized-readwrite-to-collections.html" rel="alternate"></link><published>2021-04-12T00:00:00+00:00</published><updated>2021-04-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2021-04-12:/cve-2021-29943-apache-solr-unprivileged-users-may-be-able-to-perform-unauthorized-readwrite-to-collections.html</id><summary type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.8.1</p> |
| <p><strong>Description:</strong> |
| When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect …</p></summary><content type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.8.1</p> |
| <p><strong>Description:</strong> |
| When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.</p> |
| <p><strong>Mitigation:</strong> |
| Any of the following are enough to prevent this vulnerability:</p> |
| <ul> |
| <li>Upgrade to <code>Solr 8.8.2</code> or greater.</li> |
| <li>If upgrading is not an option, consider applying the patch in <a href="https://issues.apache.org/jira/browse/SOLR-15233">SOLR-15233</a></li> |
| <li>Use a different authentication plugin, such as the KerberosPlugin or HadoopAuthPlugin</li> |
| </ul> |
| <p><strong>Credit:</strong> |
| Geza Nagy</p> |
| <p><strong>References:</strong> |
| <a href="https://issues.apache.org/jira/browse/SOLR-15233">SOLR-15233</a>: CVE-2021-29943: Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections </p></content><category term="solr/security"></category></entry><entry><title>CVE-2020-13957: The checks added to unauthenticated configset uploads in Apache Solr can be circumvented</title><link href="/cve-2020-13957-the-checks-added-to-unauthenticated-configset-uploads-in-apache-solr-can-be-circumvented.html" rel="alternate"></link><published>2020-10-12T00:00:00+00:00</published><updated>2020-10-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2020-10-12:/cve-2020-13957-the-checks-added-to-unauthenticated-configset-uploads-in-apache-solr-can-be-circumvented.html</id><summary type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 6.6.0 to 6.6.6 |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.6.2</p> |
| <p><strong>Description:</strong> |
| Solr prevents some features considered dangerous (which could be used for remote code execution) to be configured in a ConfigSet that's uploaded via API …</p></summary><content type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Versions Affected:</strong> |
| 6.6.0 to 6.6.6 |
| 7.0.0 to 7.7.3 |
| 8.0.0 to 8.6.2</p> |
| <p><strong>Description:</strong> |
| Solr prevents some features considered dangerous (which could be used for remote code execution) to be configured in a ConfigSet that's uploaded via API without authentication/authorization. The checks in place to prevent such features can be circumvented by using a combination of UPLOAD/CREATE actions.</p> |
| <p><strong>Mitigation:</strong> |
| Any of the following are enough to prevent this vulnerability:</p> |
| <ul> |
| <li>Disable UPLOAD command in ConfigSets API if not used by setting the system property: <code>configset.upload.enabled</code> to <code>false</code> (<a href="https://solr.apache.org/guide/8_6/configsets-api.html">see docs</a>)</li> |
| <li>Use Authentication/Authorization and make sure unknown requests aren't allowed (<a href="https://solr.apache.org/guide/8_6/authentication-and-authorization-plugins.html">see docs</a>)</li> |
| <li>Upgrade to <code>Solr 8.6.3</code> or greater.</li> |
| <li>If upgrading is not an option, consider applying the patch in <a href="https://issues.apache.org/jira/browse/SOLR-14663">SOLR-14663</a></li> |
| <li>No Solr API, including the Admin UI, is designed to be exposed to non-trusted parties. Tune your firewall so that only trusted computers and people are allowed access</li> |
| </ul> |
| <p><strong>Credit:</strong> |
| Tomás Fernández Löbbe, András Salamon</p> |
| <p><strong>References:</strong> |
| <a href="https://issues.apache.org/jira/browse/SOLR-14925">SOLR-14925</a>: CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented</p></content><category term="solr/security"></category></entry><entry><title>CVE-2020-13941: Apache Solr information disclosure vulnerability</title><link href="/cve-2020-13941-apache-solr-information-disclosure-vulnerability.html" rel="alternate"></link><published>2020-08-14T00:00:00+00:00</published><updated>2020-08-14T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2020-08-14:/cve-2020-13941-apache-solr-information-disclosure-vulnerability.html</id><summary type="html"><p><strong>Severity:</strong> |
| Medium</p> |
| <p><strong>Versions Affected:</strong><br> |
| Before Solr 8.6. Some risks are specific to Windows.</p> |
| <p><strong>Description:</strong> |
| Reported in SOLR-14515 (private) and fixed in SOLR-14561 (public), released in Solr version 8.6.0. |
| The Replication handler (https://solr.apache.org/guide/8_6/index-replication.html#http-api-commands-for-the-replicationhandler) allows commands backup, restore and deleteBackup. Each …</p></summary><content type="html"><p><strong>Severity:</strong> |
| Medium</p> |
| <p><strong>Versions Affected:</strong><br> |
| Before Solr 8.6. Some risks are specific to Windows.</p> |
| <p><strong>Description:</strong> |
| Reported in SOLR-14515 (private) and fixed in SOLR-14561 (public), released in Solr version 8.6.0. |
| The Replication handler (https://solr.apache.org/guide/8_6/index-replication.html#http-api-commands-for-the-replicationhandler) allows commands backup, restore and deleteBackup. Each of these take a location parameter, which was not validated, i.e you could read/write to any location the solr user can access. </p> |
| <p>On a windows system SMB paths such as \10.0.0.99\share\folder may also be used, leading to:</p> |
| <ul> |
| <li>The possibility of restoring another SolrCore from a server on the network (or mounted remote file system) may lead to:<ul> |
| <li>Exposing search index data that the attacker should otherwise not have access to</li> |
| <li>Replacing the index data entirely by loading it from a remote file system that the attacker controls</li> |
| </ul> |
| </li> |
| <li>Launching SMB attacks which may result in:<ul> |
| <li>The exfiltration of sensitive data such as OS user hashes (NTLM/LM hashes),</li> |
| <li>In case of misconfigured systems, SMB Relay Attacks which can lead to user impersonation on SMB Shares or, in a worse-case scenario, Remote Code Execution </li> |
| </ul> |
| </li> |
| </ul> |
| <p><strong>Mitigation:</strong> |
| Upgrade to Solr 8.6, and/or ensure only trusted clients can make requests of Solr's replication handler.</p> |
| <p><strong>Credit:</strong> |
| Matei "Mal" Badanoiu</p></content><category term="solr/security"></category></entry><entry><title>CVE-2019-17558: Apache Solr RCE through VelocityResponseWriter</title><link href="/cve-2019-17558-apache-solr-rce-through-velocityresponsewriter.html" rel="alternate"></link><published>2019-12-30T00:00:00+00:00</published><updated>2019-12-30T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-12-30:/cve-2019-17558-apache-solr-rce-through-velocityresponsewriter.html</id><summary type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong> |
| 5.0.0 to 8.3.1</p> |
| <p><strong>Description:</strong><br> |
| The affected versions are vulnerable to a Remote Code Execution through the |
| VelocityResponseWriter. A Velocity template can be provided through |
| Velocity templates in a configset <code>velocity/</code> directory or as a parameter. |
| A user …</p></summary><content type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong> |
| 5.0.0 to 8.3.1</p> |
| <p><strong>Description:</strong><br> |
| The affected versions are vulnerable to a Remote Code Execution through the |
| VelocityResponseWriter. A Velocity template can be provided through |
| Velocity templates in a configset <code>velocity/</code> directory or as a parameter. |
| A user defined configset could contain renderable, potentially malicious, |
| templates. Parameter provided templates are disabled by default, but can |
| be enabled by setting <code>params.resource.loader.enabled</code> by defining a |
| response writer with that setting set to <code>true</code>. Defining a response |
| writer requires configuration API access.</p> |
| <p>Solr 8.4 removed the params resource loader entirely, and only enables the |
| configset-provided template rendering when the configset is <code>trusted</code> (has |
| been uploaded by an authenticated user).</p> |
| <p><strong>Mitigation:</strong><br> |
| Ensure your network settings are configured so that only trusted traffic |
| communicates with Solr, especially to the configuration APIs.</p> |
| <p><strong>Credit:</strong><br> |
| Github user <code>s00py</code></p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-13971">https://issues.apache.org/jira/browse/SOLR-13971</a></li> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-14025">https://issues.apache.org/jira/browse/SOLR-14025</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity">https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2019-12409: Apache Solr RCE vulnerability due to bad config default</title><link href="/cve-2019-12409-apache-solr-rce-vulnerability-due-to-bad-config-default.html" rel="alternate"></link><published>2019-11-18T00:00:00+00:00</published><updated>2019-11-18T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-11-18:/cve-2019-12409-apache-solr-rce-vulnerability-due-to-bad-config-default.html</id><summary type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr 8.1.1 and 8.2.0 for Linux</p> |
| <p><strong>Description:</strong><br> |
| The 8.1.1 and 8.2.0 releases of Apache Solr contain an |
| insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option |
| in the default solr.in.sh configuration file shipping …</p></summary><content type="html"><p><strong>Severity:</strong> |
| High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr 8.1.1 and 8.2.0 for Linux</p> |
| <p><strong>Description:</strong><br> |
| The 8.1.1 and 8.2.0 releases of Apache Solr contain an |
| insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option |
| in the default solr.in.sh configuration file shipping with Solr.</p> |
| <p>Windows users are not affected.</p> |
| <p>If you use the default solr.in.sh file from the affected releases, then |
| JMX monitoring will be enabled and exposed on RMI_PORT (default=18983), |
| without any authentication. If this port is opened for inbound traffic |
| in your firewall, then anyone with network access to your Solr nodes |
| will be able to access JMX, which may in turn allow them to upload |
| malicious code for execution on the Solr server.</p> |
| <p>The vulnerability is already public [1] and mitigation steps were |
| announced on project mailing lists and news page [3] on August 14th, |
| without mentioning RCE at that time.</p> |
| <p><strong>Mitigation:</strong><br> |
| Make sure your effective solr.in.sh file has ENABLE_REMOTE_JMX_OPTS set |
| to 'false' on every Solr node and then restart Solr. Note that the |
| effective solr.in.sh file may reside in /etc/defaults/ or another |
| location depending on the install. You can then validate that the |
| 'com.sun.management.jmxremote*' family of properties are not listed in |
| the "Java Properties" section of the Solr Admin UI, or configured in a |
| secure way.</p> |
| <p>There is no need to upgrade or update any code.</p> |
| <p>Remember to follow the Solr Documentation's advice to never expose Solr |
| nodes directly in a hostile network environment.</p> |
| <p><strong>Credit:</strong><br> |
| Matei "Mal" Badanoiu<br> |
| Solr JIRA user 'jnyryan' (John)</p> |
| <p><strong>References:</strong><br> |
| [1] https://issues.apache.org/jira/browse/SOLR-13647<br> |
| [3] https://solr.apache.org/news.html</p></content><category term="solr/security"></category></entry><entry><title>CVE-2019-12401: XML Bomb in Apache Solr versions prior to 5.0</title><link href="/cve-2019-12401-xml-bomb-in-apache-solr-versions-prior-to-50.html" rel="alternate"></link><published>2019-09-09T00:00:00+00:00</published><updated>2019-09-09T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-09-09:/cve-2019-12401-xml-bomb-in-apache-solr-versions-prior-to-50.html</id><summary type="html"><p><strong>Severity:</strong> Medium</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>1.3.0 to 1.4.1</li> |
| <li>3.1.0 to 3.6.2</li> |
| <li>4.0.0 to 4.10.4</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Solr versions prior to 5.0.0 are vulnerable to an XML resource |
| consumption attack (a.k.a. Lol …</p></summary><content type="html"><p><strong>Severity:</strong> Medium</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>1.3.0 to 1.4.1</li> |
| <li>3.1.0 to 3.6.2</li> |
| <li>4.0.0 to 4.10.4</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Solr versions prior to 5.0.0 are vulnerable to an XML resource |
| consumption attack (a.k.a. Lol Bomb) via it’s update handler. By leveraging |
| XML DOCTYPE and ENTITY type elements, the attacker can create a pattern |
| that will expand when the server parses the XML causing OOMs</p> |
| <p><strong>Mitigation:</strong> </p> |
| <ul> |
| <li>Upgrade to Apache Solr 5.0 or later.</li> |
| <li>Ensure your network settings are configured so that only trusted traffic is allowed to post documents to the running Solr instances.</li> |
| </ul> |
| <p><strong>Credit:</strong><br> |
| Matei "Mal" Badanoiu</p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-13750">https://issues.apache.org/jira/browse/SOLR-13750</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity">https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>[ANNOUNCE] 8.1.1 and 8.2.0 users check ENABLE_REMOTE_JMX_OPTS setting</title><link href="/announce-811-and-820-users-check-enable_remote_jmx_opts-setting.html" rel="alternate"></link><published>2019-08-14T00:00:00+00:00</published><updated>2019-08-14T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-08-14:/announce-811-and-820-users-check-enable_remote_jmx_opts-setting.html</id><summary type="html"><div class="codehilite"><pre><span></span><code><span class="n">Severity</span><span class="o">:</span> <span class="n">Low</span> |
| |
| <span class="n">Versions</span> <span class="n">Affected</span><span class="o">:</span> |
| <span class="mf">8.1</span><span class="o">.</span><span class="mi">1</span> <span class="n">and</span> <span class="mf">8.2</span><span class="o">.</span><span class="mi">0</span> <span class="k">for</span> <span class="n">Linux</span> |
| |
| <span class="n">Description</span><span class="o">:</span> |
| <span class="n">It</span> <span class="n">has</span> <span class="n">been</span> <span class="n">discovered</span> <span class="o">[</span><span class="mi">1</span><span class="o">]</span> <span class="n">that</span> <span class="n">the</span> <span class="mf">8.1</span><span class="o">.</span><span class="mi">1</span> <span class="n">and</span> <span class="mf">8.2</span><span class="o">.</span><span class="mi">0</span> <span class="n">releases</span> <span class="n">contain</span> <span class="n">a</span> <span class="n">bad</span> <span class="k">default</span> |
| <span class="n">setting</span> <span class="k">for</span> <span class="n">the</span> <span class="n">ENABLE_REMOTE_JMX_OPTS</span> <span class="n">setting</span> <span class="k">in</span> <span class="n">the</span> <span class="k">default</span> <span class="n">solr</span><span class="o">.</span><span class="na">in</span><span class="o">.</span><span class="na">sh</span> <span class="n">file</span> |
| <span class="n">shipping</span> <span class="k">with</span> <span class="n">Solr</span><span class="o">.</span> |
| |
| <span class="n">Windows</span> <span class="n">users …</span></code></pre></div></summary><content type="html"><div class="codehilite"><pre><span></span><code><span class="n">Severity</span><span class="o">:</span> <span class="n">Low</span> |
| |
| <span class="n">Versions</span> <span class="n">Affected</span><span class="o">:</span> |
| <span class="mf">8.1</span><span class="o">.</span><span class="mi">1</span> <span class="n">and</span> <span class="mf">8.2</span><span class="o">.</span><span class="mi">0</span> <span class="k">for</span> <span class="n">Linux</span> |
| |
| <span class="n">Description</span><span class="o">:</span> |
| <span class="n">It</span> <span class="n">has</span> <span class="n">been</span> <span class="n">discovered</span> <span class="o">[</span><span class="mi">1</span><span class="o">]</span> <span class="n">that</span> <span class="n">the</span> <span class="mf">8.1</span><span class="o">.</span><span class="mi">1</span> <span class="n">and</span> <span class="mf">8.2</span><span class="o">.</span><span class="mi">0</span> <span class="n">releases</span> <span class="n">contain</span> <span class="n">a</span> <span class="n">bad</span> <span class="k">default</span> |
| <span class="n">setting</span> <span class="k">for</span> <span class="n">the</span> <span class="n">ENABLE_REMOTE_JMX_OPTS</span> <span class="n">setting</span> <span class="k">in</span> <span class="n">the</span> <span class="k">default</span> <span class="n">solr</span><span class="o">.</span><span class="na">in</span><span class="o">.</span><span class="na">sh</span> <span class="n">file</span> |
| <span class="n">shipping</span> <span class="k">with</span> <span class="n">Solr</span><span class="o">.</span> |
| |
| <span class="n">Windows</span> <span class="n">users</span> <span class="n">and</span> <span class="n">users</span> <span class="k">with</span> <span class="n">custom</span> <span class="n">solr</span><span class="o">.</span><span class="na">in</span><span class="o">.</span><span class="na">sh</span> <span class="n">files</span> <span class="n">are</span> <span class="n">not</span> <span class="n">affected</span><span class="o">.</span> |
| |
| <span class="n">If</span> <span class="n">you</span> <span class="n">are</span> <span class="n">using</span> <span class="n">the</span> <span class="k">default</span> <span class="n">solr</span><span class="o">.</span><span class="na">in</span><span class="o">.</span><span class="na">sh</span> <span class="n">file</span> <span class="n">from</span> <span class="n">the</span> <span class="n">affected</span> <span class="n">releases</span><span class="o">,</span> <span class="n">then</span> |
| <span class="n">JMX</span> <span class="n">monitoring</span> <span class="n">will</span> <span class="n">be</span> <span class="n">enabled</span> <span class="n">and</span> <span class="n">exposed</span> <span class="n">on</span> <span class="n">JMX_PORT</span> <span class="o">(</span><span class="k">default</span> <span class="o">=</span> <span class="mi">18983</span><span class="o">),</span> |
| <span class="n">without</span> <span class="n">any</span> <span class="n">authentication</span><span class="o">.</span> <span class="n">So</span> <span class="k">if</span> <span class="n">your</span> <span class="n">firewalls</span> <span class="n">allows</span> <span class="n">inbound</span> <span class="n">traffic</span> <span class="n">on</span> |
| <span class="n">JMX_PORT</span><span class="o">,</span> <span class="n">then</span> <span class="n">anyone</span> <span class="k">with</span> <span class="n">network</span> <span class="n">access</span> <span class="n">to</span> <span class="n">your</span> <span class="n">Solr</span> <span class="n">nodes</span> <span class="n">will</span> <span class="n">be</span> <span class="n">able</span> <span class="n">to</span> |
| <span class="n">access</span> <span class="n">monitoring</span> <span class="n">data</span> <span class="n">exposed</span> <span class="n">over</span> <span class="n">JMX</span><span class="o">.</span> |
| |
| <span class="n">Mitigation</span><span class="o">:</span> |
| <span class="n">Edit</span> <span class="n">solr</span><span class="o">.</span><span class="na">in</span><span class="o">.</span><span class="na">sh</span><span class="o">,</span> <span class="kd">set</span> <span class="n">ENABLE_REMOTE_JMX_OPTS</span><span class="o">=</span><span class="kc">false</span> <span class="n">and</span> <span class="n">restart</span> <span class="n">Solr</span><span class="o">.</span> |
| <span class="n">Alternatively</span> <span class="n">wait</span> <span class="k">for</span> <span class="n">the</span> <span class="n">future</span> <span class="mf">8.3</span><span class="o">.</span><span class="mi">0</span> <span class="n">release</span> <span class="n">and</span> <span class="n">upgrade</span><span class="o">.</span> |
| |
| <span class="n">References</span><span class="o">:</span> |
| <span class="o">[</span><span class="mi">1</span><span class="o">]</span> <span class="n">https</span><span class="o">://</span><span class="n">issues</span><span class="o">.</span><span class="na">apache</span><span class="o">.</span><span class="na">org</span><span class="sr">/jira/browse/</span><span class="n">SOLR</span><span class="o">-</span><span class="mi">13647</span> |
| </code></pre></div></content><category term="solr/security"></category></entry><entry><title>CVE-2019-0193: Apache Solr, Remote Code Execution via DataImportHandler</title><link href="/cve-2019-0193-apache-solr-remote-code-execution-via-dataimporthandler.html" rel="alternate"></link><published>2019-07-31T00:00:00+00:00</published><updated>2019-07-31T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-07-31:/cve-2019-0193-apache-solr-remote-code-execution-via-dataimporthandler.html</id><summary type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>5.0.0 to 5.5.5</li> |
| <li>6.0.0 to 6.6.5</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| The DataImportHandler, an optional but popular module to pull in data from |
| databases and other sources, has a feature in which the whole DIH |
| configuration can …</p></summary><content type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>5.0.0 to 5.5.5</li> |
| <li>6.0.0 to 6.6.5</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| The DataImportHandler, an optional but popular module to pull in data from |
| databases and other sources, has a feature in which the whole DIH |
| configuration can come from a request's "dataConfig" parameter. The debug |
| mode of the DIH admin screen uses this to allow convenient debugging / |
| development of a DIH config. Since a DIH config can contain scripts, this |
| parameter is a security risk. Starting with version 8.2.0 of Solr, use of |
| this parameter requires setting the Java System property |
| <code>enable.dih.dataConfigParam</code> to true.</p> |
| <p><strong>Mitigation:</strong> </p> |
| <ul> |
| <li>Upgrade to 8.2.0 or later, which is secure by default.</li> |
| <li>or, edit solrconfig.xml to configure all DataImportHandler usages with an "invariants" section listing the "dataConfig" parameter set to am empty string.</li> |
| <li>Ensure your network settings are configured so that only trusted traffic communicates with Solr, especially to the DIH request handler. This is a best practice to all of Solr.</li> |
| </ul> |
| <p><strong>Credit:</strong><br> |
| Michael Stepankin (JPMorgan Chase)</p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-13669">https://issues.apache.org/jira/browse/SOLR-13669</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity">https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2019-0192: Deserialization of untrusted data via jmx.serviceUrl in Apache Solr</title><link href="/cve-2019-0192-deserialization-of-untrusted-data-via-jmxserviceurl-in-apache-solr.html" rel="alternate"></link><published>2019-03-06T00:00:00+00:00</published><updated>2019-03-06T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-03-06:/cve-2019-0192-deserialization-of-untrusted-data-via-jmxserviceurl-in-apache-solr.html</id><summary type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>5.0.0 to 5.5.5</li> |
| <li>6.0.0 to 6.6.5</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| ConfigAPI allows to configure Solr's JMX server via an HTTP POST request. |
| By pointing it to a malicious RMI server, an attacker could take advantage |
| of …</p></summary><content type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>5.0.0 to 5.5.5</li> |
| <li>6.0.0 to 6.6.5</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| ConfigAPI allows to configure Solr's JMX server via an HTTP POST request. |
| By pointing it to a malicious RMI server, an attacker could take advantage |
| of Solr's unsafe deserialization to trigger remote code execution on the |
| Solr side.</p> |
| <p><strong>Mitigation:</strong><br> |
| Any of the following are enough to prevent this vulnerability:</p> |
| <ul> |
| <li>Upgrade to Apache Solr 7.0 or later.</li> |
| <li>Disable the ConfigAPI if not in use, by running Solr with the system property “disable.configEdit=true”</li> |
| <li>If upgrading or disabling the Config API are not viable options, apply patch in [1] and re-compile Solr.</li> |
| <li>Ensure your network settings are configured so that only trusted traffic is allowed to ingress/egress your hosts running Solr.</li> |
| </ul> |
| <p><strong>Credit:</strong><br> |
| Michael Stepankin</p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-13301">https://issues.apache.org/jira/browse/SOLR-13301</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity">https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2017-3164: SSRF issue in Apache Solr</title><link href="/cve-2017-3164-ssrf-issue-in-apache-solr.html" rel="alternate"></link><published>2019-02-12T00:00:00+00:00</published><updated>2019-02-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2019-02-12:/cve-2017-3164-ssrf-issue-in-apache-solr.html</id><summary type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong> |
| Apache Solr versions from 1.3 to 7.6.0</p> |
| <p><strong>Description:</strong><br> |
| The "shards" parameter does not have a corresponding whitelist mechanism, |
| so it can request any URL.</p> |
| <p><strong>Mitigation:</strong><br> |
| Upgrade to Apache Solr 7.7.0 or later. |
| Ensure your network settings …</p></summary><content type="html"><p><strong>Severity:</strong> High</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong> |
| Apache Solr versions from 1.3 to 7.6.0</p> |
| <p><strong>Description:</strong><br> |
| The "shards" parameter does not have a corresponding whitelist mechanism, |
| so it can request any URL.</p> |
| <p><strong>Mitigation:</strong><br> |
| Upgrade to Apache Solr 7.7.0 or later. |
| Ensure your network settings are configured so that only trusted traffic is |
| allowed to ingress/egress your hosts running Solr.</p> |
| <p><strong>Credit:</strong><br> |
| dk from Chaitin Tech</p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-12770">https://issues.apache.org/jira/browse/SOLR-12770</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity">https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2018-1308: XXE attack through Apache Solr's DIH's dataConfig request parameter</title><link href="/cve-2018-1308-xxe-attack-through-apache-solrs-dihs-dataconfig-request-parameter.html" rel="alternate"></link><published>2018-04-08T00:00:00+00:00</published><updated>2018-04-08T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2018-04-08:/cve-2018-1308-xxe-attack-through-apache-solrs-dihs-dataconfig-request-parameter.html</id><summary type="html"><p>CVE-2018-1308: XXE attack through Apache Solr's DIH's dataConfig request parameter</p> |
| <p><strong>Severity:</strong> Major</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Solr 1.2 to 6.6.2</li> |
| <li>Solr 7.0.0 to 7.2.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| The details of this vulnerability were reported to the Apache Security mailing list. </p> |
| <p>This vulnerability …</p></summary><content type="html"><p>CVE-2018-1308: XXE attack through Apache Solr's DIH's dataConfig request parameter</p> |
| <p><strong>Severity:</strong> Major</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Solr 1.2 to 6.6.2</li> |
| <li>Solr 7.0.0 to 7.2.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| The details of this vulnerability were reported to the Apache Security mailing list. </p> |
| <p>This vulnerability relates to an XML external entity expansion (XXE) in the |
| <code>&amp;dataConfig=&lt;inlinexml&gt;</code> parameter of Solr's DataImportHandler. It can be |
| used as XXE using file/ftp/http protocols in order to read arbitrary local |
| files from the Solr server or the internal network. See [1] for more details.</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are advised to upgrade to either Solr 6.6.3 or Solr 7.3.0 releases both |
| of which address the vulnerability. Once upgrade is complete, no other steps |
| are required. Those releases disable external entities in anonymous XML files |
| passed through this request parameter. </p> |
| <p>If users are unable to upgrade to Solr 6.6.3 or Solr 7.3.0 then they are |
| advised to disable data import handler in their solrconfig.xml file and |
| restart their Solr instances. Alternatively, if Solr instances are only used |
| locally without access to public internet, the vulnerability cannot be used |
| directly, so it may not be required to update, and instead reverse proxies or |
| Solr client applications should be guarded to not allow end users to inject |
| <code>dataConfig</code> request parameters. Please refer to [2] on how to correctly |
| secure Solr servers.</p> |
| <p><strong>Credit:</strong><br> |
| 麦 香浓郁</p> |
| <p><strong>References:</strong></p> |
| <p>[1] <a href="https://issues.apache.org/jira/browse/SOLR-11971">https://issues.apache.org/jira/browse/SOLR-11971</a><br> |
| [2] <a href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></p></content><category term="solr/security"></category></entry><entry><title>CVE-2016-6809: Java code execution for serialized objects embedded in MATLAB files parsed by Apache Solr using Tika</title><link href="/cve-2016-6809-java-code-execution-for-serialized-objects-embedded-in-matlab-files-parsed-by-apache-solr-using-tika.html" rel="alternate"></link><published>2017-10-26T00:00:00+00:00</published><updated>2017-10-26T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2017-10-26:/cve-2016-6809-java-code-execution-for-serialized-objects-embedded-in-matlab-files-parsed-by-apache-solr-using-tika.html</id><summary type="html"><p><strong>Severity:</strong> Important</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Solr 5.0.0 to 5.5.4</li> |
| <li>Solr 6.0.0 to 6.6.1</li> |
| <li>Solr 7.0.0 to 7.0.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Apache Solr uses Apache Tika for parsing binary file types such as |
| doc, xls, pdf etc …</p></summary><content type="html"><p><strong>Severity:</strong> Important</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong></p> |
| <ul> |
| <li>Solr 5.0.0 to 5.5.4</li> |
| <li>Solr 6.0.0 to 6.6.1</li> |
| <li>Solr 7.0.0 to 7.0.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Apache Solr uses Apache Tika for parsing binary file types such as |
| doc, xls, pdf etc. Apache Tika wraps the jmatio parser |
| (https://github.com/gradusnikov/jmatio) to handle MATLAB files. The |
| parser uses native deserialization on serialized Java objects embedded |
| in MATLAB files. A malicious user could inject arbitrary code into a |
| MATLAB file that would be executed when the object is deserialized.</p> |
| <p>This vulnerability was originally described at |
| http://mail-archives.apache.org/mod_mbox/tika-user/201611.mbox/%3C2125912914.1308916.1478787314903%40mail.yahoo.com%3E</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are advised to upgrade to either Solr 5.5.5 or Solr 6.6.2 or Solr 7.1.0 |
| releases which have fixed this vulnerability.</p> |
| <p>Solr 5.5.5 upgrades the jmatio parser to v1.2 and disables the Java |
| deserialisation support to protect against this vulnerability.</p> |
| <p>Solr 6.6.2 and Solr 7.1.0 have upgraded the bundled Tika to v1.16.</p> |
| <p>Once upgrade is complete, no other steps are required.</p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-11486">https://issues.apache.org/jira/browse/SOLR-11486</a></li> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-10335">https://issues.apache.org/jira/browse/SOLR-10335</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>Several critical vulnerabilities discovered in Apache Solr (XXE & RCE)</title><link href="/several-critical-vulnerabilities-discovered-in-apache-solr-xxe-rce.html" rel="alternate"></link><published>2017-10-18T00:00:00+00:00</published><updated>2017-10-18T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2017-10-18:/several-critical-vulnerabilities-discovered-in-apache-solr-xxe-rce.html</id><summary type="html"><p><strong>Severity:</strong><br> |
| Critical</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong> </p> |
| <ul> |
| <li>Solr 5.5.0 to 5.5.4</li> |
| <li>Solr 6.0.0 to 6.6.1</li> |
| <li>Solr 7.0.0 to 7.0.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| The details of this vulnerability were reported on public mailing |
| lists. See https://s.apache.org …</p></summary><content type="html"><p><strong>Severity:</strong><br> |
| Critical</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong> </p> |
| <ul> |
| <li>Solr 5.5.0 to 5.5.4</li> |
| <li>Solr 6.0.0 to 6.6.1</li> |
| <li>Solr 7.0.0 to 7.0.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| The details of this vulnerability were reported on public mailing |
| lists. See https://s.apache.org/FJDl</p> |
| <p>The first vulnerability relates to XML external entity expansion in |
| the XML Query Parser which is available, by default, for any query |
| request with parameters deftype=xmlparser. This can be exploited to |
| upload malicious data to the /upload request handler. It can also be |
| used as Blind XXE using ftp wrapper in order to read arbitrary local |
| files from the solr server.</p> |
| <p>The second vulnerability relates to remote code execution using the |
| RunExecutableListener available on all affected versions of Solr.</p> |
| <p>At the time of the above report, this was a 0-day vulnerability with a |
| working exploit affecting the versions of Solr mentioned in the |
| previous section. However, mitigation steps were announced to protect |
| Solr users the same day. See |
| https://solr.apache.org/news.html#12-october-2017-please-secure-your-apache-solr-servers-since-a-zero-day-exploit-has-been-reported-on-a-public-mailing-list</p> |
| <p><strong>Mitigation:</strong><br> |
| Users are advised to upgrade to either Solr 6.6.2 or Solr 7.1.0 |
| releases both of which address the two vulnerabilities. Once upgrade is |
| complete, no other steps are required.</p> |
| <p>If users are unable to upgrade to Solr 6.6.2 or Solr 7.1.0 then they |
| are advised to restart their Solr instances with the system parameter |
| <code>-Ddisable.configEdit=true</code>. This will disallow any changes to be made |
| to your configurations via the Config API. This is a key factor in |
| this vulnerability, since it allows GET requests to add the |
| RunExecutableListener to your config. Users are also advised to re-map |
| the XML Query Parser to another parser to mitigate the XXE |
| vulnerability. For example, adding the following to the solrconfig.xml |
| file re-maps the xmlparser to the edismax parser: |
| <code>&lt;queryParser name="xmlparser" class="solr.ExtendedDismaxQParserPlugin"/&gt;</code></p> |
| <p><strong>Credit:</strong> </p> |
| <ul> |
| <li>Michael Stepankin (JPMorgan Chase)</li> |
| <li>Olga Barinova (Gotham Digital Science)</li> |
| </ul> |
| <p><strong>References:</strong> </p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-11482">https://issues.apache.org/jira/browse/SOLR-11482</a></li> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-11477">https://issues.apache.org/jira/browse/SOLR-11477</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>Please secure your Apache Solr servers since a zero-day exploit has been reported on a public mailing list</title><link href="/solr-security-please-secure-your-apache-solr-servers-since-a-zero-day-exploit-has-been-reported-on-a-public-mailing-list.html" rel="alternate"></link><published>2017-10-12T00:00:00+00:00</published><updated>2017-10-12T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2017-10-12:/solr-security-please-secure-your-apache-solr-servers-since-a-zero-day-exploit-has-been-reported-on-a-public-mailing-list.html</id><summary type="html"><p>Please secure your Solr servers since a zero-day exploit has been |
| reported on a <a href="https://s.apache.org/FJDl">public mailing list</a>. |
| This has been assigned a public CVE (CVE-2017-12629) which we |
| will reference in future communication about resolution and mitigation |
| steps.</p> |
| <p>Here is what we're recommending and what we're doing now:</p> |
| <ul> |
| <li> |
| <p>Until fixes are …</p></li></ul></summary><content type="html"><p>Please secure your Solr servers since a zero-day exploit has been |
| reported on a <a href="https://s.apache.org/FJDl">public mailing list</a>. |
| This has been assigned a public CVE (CVE-2017-12629) which we |
| will reference in future communication about resolution and mitigation |
| steps.</p> |
| <p>Here is what we're recommending and what we're doing now:</p> |
| <ul> |
| <li> |
| <p>Until fixes are available, all Solr users are advised to restart their |
| Solr instances with the system property <code>-Ddisable.configEdit=true</code>. |
| This will disallow any changes to be made to configurations via the |
| Config API. This is a key factor in this vulnerability, since it allows |
| GET requests to add the RunExecutableListener to the config. This is |
| sufficient to protect you from this type of attack, but means you cannot |
| use the edit capabilities of the Config API until the other fixes |
| described below are in place. Users are also advised to remap |
| the XML Query Parser to another parser to mitigate the XXE |
| vulnerability. For example, adding the following to the solrconfig.xml |
| file maps the <code>xmlparser</code> to the <code>edismax</code> parser: |
| <code>&lt;queryParser name="xmlparser" class="solr.ExtendedDismaxQParserPlugin"/&gt;</code>.</p> |
| </li> |
| <li> |
| <p>A new release of Lucene/Solr was in the vote phase, but we have now |
| pulled it back to be able to address these issues in the upcoming 7.1 |
| release. We will also determine mitigation steps for users on earlier |
| versions, which may include a 6.6.2 release for users still on 6.x.</p> |
| </li> |
| <li> |
| <p>The RunExecutableListener will be removed in 7.1. It was previously |
| used by Solr for index replication but has been replaced and is no |
| longer needed.</p> |
| </li> |
| <li> |
| <p>The XML Parser will be fixed and the fixes will be included in the 7.1 |
| release.</p> |
| </li> |
| <li> |
| <p>The 7.1 release was already slated to include a change to disable the |
| <code>stream.body</code> parameter by default, which will further help protect |
| systems.</p> |
| </li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2017-9803: Security vulnerability in kerberos delegation token functionality**</title><link href="/cve-2017-9803-security-vulnerability-in-kerberos-delegation-token-functionality.html" rel="alternate"></link><published>2017-09-18T00:00:00+00:00</published><updated>2017-09-18T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2017-09-18:/cve-2017-9803-security-vulnerability-in-kerberos-delegation-token-functionality.html</id><summary type="html"><p><strong>CVE-2017-9803: Security vulnerability in kerberos delegation token functionality</strong></p> |
| <p><strong>Severity</strong>: Important</p> |
| <p><strong>Vendor</strong>:<br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected</strong>:<br> |
| Solr 6.2.0 to 6.6.0</p> |
| <p><strong>Description</strong>:</p> |
| <p>Solr's Kerberos plugin can be configured to use delegation tokens, which allows an application to reuse the authentication of an end-user or another application …</p></summary><content type="html"><p><strong>CVE-2017-9803: Security vulnerability in kerberos delegation token functionality</strong></p> |
| <p><strong>Severity</strong>: Important</p> |
| <p><strong>Vendor</strong>:<br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected</strong>:<br> |
| Solr 6.2.0 to 6.6.0</p> |
| <p><strong>Description</strong>:</p> |
| <p>Solr's Kerberos plugin can be configured to use delegation tokens, which allows an application to reuse the authentication of an end-user or another application. |
| There are two issues with this functionality (when using SecurityAwareZkACLProvider type of ACL provider e.g. SaslZkACLProvider),</p> |
| <p>Firstly, access to the security configuration can be leaked to users other than the solr super user. Secondly, malicious users can exploit this leaked configuration for privilege escalation to further expose/modify private data and/or disrupt operations in the Solr cluster.</p> |
| <p>The vulnerability is fixed from Solr 6.6.1 onwards.</p> |
| <p><strong>Mitigation</strong>:<br> |
| 6.x users should upgrade to 6.6.1</p> |
| <p><strong>Credit</strong>:<br> |
| This issue was discovered by Hrishikesh Gadre of Cloudera Inc.</p> |
| <p><strong>References</strong>:</p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-11184">https://issues.apache.org/jira/browse/SOLR-11184</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr**</title><link href="/cve-2017-7660-security-vulnerability-in-secure-inter-node-communication-in-apache-solr.html" rel="alternate"></link><published>2017-07-07T00:00:00+00:00</published><updated>2017-07-07T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2017-07-07:/cve-2017-7660-security-vulnerability-in-secure-inter-node-communication-in-apache-solr.html</id><summary type="html"><p><strong>CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr</strong></p> |
| <p><strong>Severity</strong>: Important</p> |
| <p><strong>Vendor</strong>:<br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected</strong>: </p> |
| <ul> |
| <li>Solr 5.3 to 5.5.4</li> |
| <li>Solr 6.0 to 6.5.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Solr uses a PKI based mechanism to secure inter-node communication |
| when security is enabled. It is …</p></summary><content type="html"><p><strong>CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr</strong></p> |
| <p><strong>Severity</strong>: Important</p> |
| <p><strong>Vendor</strong>:<br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected</strong>: </p> |
| <ul> |
| <li>Solr 5.3 to 5.5.4</li> |
| <li>Solr 6.0 to 6.5.1</li> |
| </ul> |
| <p><strong>Description:</strong><br> |
| Solr uses a PKI based mechanism to secure inter-node communication |
| when security is enabled. It is possible to create a specially crafted |
| node name that does not exist as part of the cluster and point it to a |
| malicious node. This can trick the nodes in cluster to believe that |
| the malicious node is a member of the cluster. So, if Solr users have |
| enabled BasicAuth authentication mechanism using the BasicAuthPlugin |
| or if the user has implemented a custom Authentication plugin, which |
| does not implement either "HttpClientInterceptorPlugin" or |
| "HttpClientBuilderPlugin", his/her servers are vulnerable to this |
| attack. Users who only use SSL without basic authentication or those |
| who use Kerberos are not affected.</p> |
| <p><strong>Mitigation</strong>:</p> |
| <ul> |
| <li>6.x users should upgrade to 6.6.0 or higher</li> |
| <li>5.x users should obtain the latest source from git and apply this patch: |
| <a href="http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2f5ecbcf">http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2f5ecbcf</a></li> |
| </ul> |
| <p><strong>Credit</strong>:<br> |
| This issue was discovered by Noble Paul of Lucidworks Inc.</p> |
| <p><strong>References</strong>:</p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-10624">https://issues.apache.org/jira/browse/SOLR-10624</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2017-3163: Apache Solr ReplicationHandler path traversal attack**</title><link href="/cve-2017-3163-apache-solr-replicationhandler-path-traversal-attack.html" rel="alternate"></link><published>2017-02-15T00:00:00+00:00</published><updated>2017-02-15T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2017-02-15:/cve-2017-3163-apache-solr-replicationhandler-path-traversal-attack.html</id><summary type="html"><p><strong>CVE-2017-3163: Apache Solr ReplicationHandler path traversal attack</strong></p> |
| <p><strong>Severity:</strong> Moderate</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr 1.4 to 6.4.0</p> |
| <p><strong>Description:</strong><br> |
| When using the Index Replication feature, Solr nodes can pull index files from |
| a master/leader node using an HTTP API which accepts a file name …</p></summary><content type="html"><p><strong>CVE-2017-3163: Apache Solr ReplicationHandler path traversal attack</strong></p> |
| <p><strong>Severity:</strong> Moderate</p> |
| <p><strong>Vendor:</strong><br> |
| The Apache Software Foundation</p> |
| <p><strong>Versions Affected:</strong><br> |
| Solr 1.4 to 6.4.0</p> |
| <p><strong>Description:</strong><br> |
| When using the Index Replication feature, Solr nodes can pull index files from |
| a master/leader node using an HTTP API which accepts a file name. However, |
| Solr did not validate the file name, hence it was possible to craft a special |
| request involving path traversal, leaving any file readable to the Solr server |
| process exposed. Solr servers protected and restricted by firewall rules |
| and/or authentication would not be at risk since only trusted clients and users |
| would gain direct HTTP access.</p> |
| <p><strong>Mitigation:</strong></p> |
| <ul> |
| <li>6.x users should upgrade to 6.4.1</li> |
| <li>5.x users should upgrade to 5.5.4</li> |
| <li>4.x, 3.x and 1.4 users should upgrade to a supported version of Solr or setup proper firewalling, or disable the ReplicationHandler if not in use.</li> |
| </ul> |
| <p><strong>Credit:</strong><br> |
| This issue was discovered by Hrishikesh Gadre of Cloudera Inc.</p> |
| <p><strong>References:</strong></p> |
| <ul> |
| <li><a href="https://issues.apache.org/jira/browse/SOLR-10031">https://issues.apache.org/jira/browse/SOLR-10031</a></li> |
| <li><a href="https://cwiki.apache.org/confluence/display/solr/SolrSecurity">https://cwiki.apache.org/confluence/display/solr/SolrSecurity</a></li> |
| </ul></content><category term="solr/security"></category></entry><entry><title>CVE-2014-3529, CVE-2014-3574: Recommendation to update Apache POI in Apache Solr 4.8.0, 4.8.1, and 4.9.0 installations</title><link href="/" rel="alternate"></link><published>2014-08-18T00:00:00+00:00</published><updated>2014-08-18T00:00:00+00:00</updated><author><name>Solr Developers</name></author><id>tag:None,2014-08-18:/</id><summary type="html"><p>Apache Solr versions 4.8.0, 4.8.1, 4.9.0 bundle Apache POI 3.10-beta2 with its binary release tarball. |
| This version (and all previous ones) of Apache POI are vulnerable to the following issues:</p> |
| <h3 id="cve-2014-3529-xml-external-entity-xxe-problem-in-apache-pois-openxml-parser">CVE-2014-3529: XML External Entity (XXE) problem in Apache POI's OpenXML parser</h3> |
| <p><em>Information disclosure …</em></p></summary><content type="html"><p>Apache Solr versions 4.8.0, 4.8.1, 4.9.0 bundle Apache POI 3.10-beta2 with its binary release tarball. |
| This version (and all previous ones) of Apache POI are vulnerable to the following issues:</p> |
| <h3 id="cve-2014-3529-xml-external-entity-xxe-problem-in-apache-pois-openxml-parser">CVE-2014-3529: XML External Entity (XXE) problem in Apache POI's OpenXML parser</h3> |
| <p><em>Information disclosure:</em> Apache POI uses Java's XML components to parse OpenXML files produced by Microsoft Office products (DOCX, XLSX, PPTX,...). |
| Applications that accept such files from end-users are vulnerable to XML External Entity (XXE) attacks, which allows remote attackers to bypass |
| security restrictions and read arbitrary files via a crafted OpenXML document that provides an XML external entity declaration in conjunction |
| with an entity reference.</p> |
| <h3 id="cve-2014-3574-xml-entity-expansion-xee-problem-in-apache-pois-openxml-parser">CVE-2014-3574: XML Entity Expansion (XEE) problem in Apache POI's OpenXML parser</h3> |
| <p><em>Denial of service:</em> Apache POI uses Java's XML components and Apache Xmlbeans to parse OpenXML files produced by Microsoft Office products |
| (DOCX, XLSX, PPTX,...). Applications that accept such files from end-users are vulnerable to XML Entity Expansion (XEE) attacks ("XML bombs"), |
| which allows remote hackers to consume large amounts of CPU resources.</p> |
| <p><strong>The Apache POI PMC released a bugfix version (3.10.1) today.</strong></p> |
| <p>Solr users are affected by these issues, if they enable the "Apache Solr Content Extraction Library (Solr Cell)" |
| contrib module from the folder "contrib/extraction" of the release tarball.</p> |
| <p>Users of Apache Solr are strongly advised to keep the module disabled if they don't use it. |
| Alternatively, users of Apache Solr 4.8.0, 4.8.1, or 4.9.0 can update the affected libraries by |
| replacing the vulnerable JAR files in the distribution folder. Users of previous versions have |
| to update their Solr release first, patching older versions is impossible.</p> |
| <h3 id="to-replace-the-vulnerable-jar-files-follow-these-steps">To replace the vulnerable JAR files follow these steps:</h3> |
| <ul> |
| <li> |
| <p>Download the <a href="http://poi.apache.org/download.html#POI-3.10.1">Apache POI 3.10.1</a> binary release.</p> |
| </li> |
| <li> |
| <p>Unzip the archive.</p> |
| </li> |
| <li> |
| <p>Delete the following files in your "solr-4.X.X/contrib/extraction/lib" folder:</p> |
| <ul> |
| <li>poi-3.10-beta2.jar</li> |
| <li>poi-ooxml-3.10-beta2.jar</li> |
| <li>poi-ooxml-schemas-3.10-beta2.jar</li> |
| <li>poi-scratchpad-3.10-beta2.jar</li> |
| <li>xmlbeans-2.3.0.jar</li> |
| </ul> |
| </li> |
| <li> |
| <p>Copy the following files from the base folder of the Apache POI distribution to the "solr-4.X.X/contrib/extraction/lib" folder:</p> |
| <ul> |
| <li>poi-3.10.1-20140818.jar</li> |
| <li>poi-ooxml-3.10.1-20140818.jar</li> |
| <li>poi-ooxml-schemas-3.10.1-20140818.jar</li> |
| <li>poi-scratchpad-3.10.1-20140818.jar</li> |
| </ul> |
| </li> |
| <li> |
| <p>Copy "xmlbeans-2.6.0.jar" from POI's "ooxml-lib/" folder to the "solr-4.X.X/contrib/extraction/lib" folder.</p> |
| </li> |
| <li> |
| <p>Verify that the "solr-4.X.X/contrib/extraction/lib" no longer contains any files with version number "3.10-beta2".</p> |
| </li> |
| <li> |
| <p>Verify that the folder contains one xmlbeans JAR file with version 2.6.0.</p> |
| </li> |
| </ul> |
| <p>If you just want to disable extraction of Microsoft Office documents, delete the files above and don't replace them. |
| "Solr Cell" will automatically detect this and disable Microsoft Office document extraction.</p> |
| <p>Coming versions of Apache Solr will have the updated libraries bundled.</p></content><category term="solr/security"></category></entry></feed> |
