In Apache Solr versions 6.5 to 9.0, Apache Calcite has a vulnerability, CVE-2022-39135, that’s exploitable in Apache Solr in SolrCloud mode. If an untrusted user supplies specific types of SQL queries to Solr’s /sql
request handler (even indirectly via proxies / other apps), then the user could perform an XML External Entity (XXE) attack. This is fixed in Solr version 9.1.0.
Response Matrix
Product | Version | CVE-2022-39135 | Fix Version | Mitigation |
Solr | 9.0 | Not vulnerable by default* | 9.1.0 | See below |
Solr | 6.5 - 8.11.2 | Vulnerable | 9.1.0 or 8.11.3† | See below |
Fusion | 5.x | Vulnerable | TBD; expected March 2023 | See below |
Fusion | 4.x | Vulnerable | Not planned | See below |
Managed Fusion | All | Vulnerable | N/A | Not required; see below |
Connected Search | All | Not vulnerable | N/A | N/A |
Attivio | All | Not vulnerable | N/A | N/A |
Attivio SearchUI | All | Not vulnerable | N/A | N/A |
App Studio | All | Not vulnerable | N/A | N/A |
*Solr version 9.0 does not have the /sql
request handler enabled by default. If using this handler, follow the Mitigation for Solr-only section below to mitigate, or upgrade to version 9.1.0.
†Solr version 8.11.3 is not a guaranteed release, but will include the fix if released. See here for details.
Mitigation for Solr-only
In Solr 9.0 and above, the /sql
request handler is not enabled by default. If not using this handler, nothing needs to be done because it’s not enabled.
In Solr 6.5 - 8.11.2, the /sql
request handler is an “implicit” handler and always enabled by default. It can be disabled, however, in any Solr installation by modifying solrconfig.xml
to include:
<requestHandler name="/sql" class="solr.NotFoundRequestHandler"/>
If the /sql
request handler is required by a client, it is recommended to sanitize the input; an industry standard practice. They should plan to upgrade to Solr 9.1 as soon as possible. See the official Solr security bulletin for details.
Mitigation for Fusion (All Versions since ~2017)
Lucidworks believes that with proper security standards for Fusion it would not be possible for an outside actor to exploit this vulnerability. These standards are: controlling pod ingress or access to the Fusion servers; not allowing anonymous queries to be sent without authentication and authorization; and controlling who has access to write custom code in pipelines and jobs.
All Fusion versions since ~2017 use some version of Solr 6.5 - 8.11.2, and therefore the mitigation steps listed in the section above are applicable:
In Solr 6.5-8.11.2, the /sql
request handler is an “implicit” handler and always enabled by default. It can be disabled, however, in any Solr installation by modifying solrconfig.xml
to include:
<requestHandler name="/sql" class="solr.NotFoundRequestHandler"/>
Note that despite the similarities in names, the Solr /sql
request handler is not used for Fusion SQL queries. Anyone using older releases of Fusion SQL (pre-Fusion 5.6.0, when the service was removed) do not have to have this handler enabled.
If the /sql
request handler is required by a client, it is recommended to sanitize the input; an industry standard practice. They should plan to upgrade to a version of Fusion that includes Solr 9.1 as soon as possible (currently expected March 2023).
Mitigation for Managed Fusion
Lucidworks has ensured proper security standards are implemented for all Managed Fusion instances, which prevent any exploitation of CVE-2022-39135. As such, no actions are required by clients or Lucidworks to mitigate this vulnerability.
Comments
0 comments
Article is closed for comments.