Solr ReplicationHandler Path Traversal Vulnerability

In early 2017, a vulnerability was discovered in Solr's ReplicationHandler. This vulnerability exposes Solr to a path traversal attack through the Replication Handler API. 

Versions Affected

Solr 6.4.0 and all versions 5.5.3 and lower

Description of the Vulnerability

When indexes are replicated (via Index Replication or SolrCloud), Solr nodes can pull index files from a master/leader node using a Replication Hander API (exposed over HTTP or HTTPS), 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 by the Solr server process exposed.

All Solr servers using the Replication Handler are exposed to this vulnerability.

Solr servers protected by Solr's user authentication layer are considered at less risk, as are servers with firewall rules that restrict all HTTP access to only clients and users who are allowed access to the files on the box. However, a firewall and authentication are not total solutions, since any internal clients or sophisticated users with HTTP access could still potentially gain further access to the system beyond their authorization level.

The fix for this vulnerability validates the filename and ensures that any path provided is not outside the Solr installation.

More details about this vulnerability and how it was fixed are available from the JIRA issue: SOLR-10031. The CVE number is CVE-2017-3163.

How to Protect Against It

There are several ways to protect against this vulnerability without upgrading:

1) If you have authentication enabled, you can restrict access to the Replication Handler API to trusted users using Solr's Rule-based Authorization capability.

When using basic authentication, you can do this with the following API command:

curl --user $adminUsername:$adminPassword -H 'Content-type:application/json' -d '{ 
"set-permission": {
"role": "a-role-that-does-not-exist"
}' http://localhost:8983/solr/admin/authorization

2) If you do not want to enable authentication, you can restrict access to the Solr server to only trusted systems and users by either:

a. Using firewall rules to lock down access to the Solr endpoint to trusted systems and users who should have the same or greater access as the Solr system process (preferred), or

b. Restricting the Solr system process to only have access to the Solr-related directories on disk (less protection since this still exposes all files available to Solr).

Option #1 above (rule-based authorization to lock down the replication handler) is the most secure of these options, with option #2 providing some workarounds if enabling authentication and authorization is not an option for you.

However, for the best protection, we recommend upgrading to a newer version of Solr in which this vulnerability has already been fixed:

  • Solr 6.x users should upgrade to 6.4.2 or higher (6.4.2 Release Notes)
  • Solr 5.x users should upgrade to 5.5.4 or higher (5.5.4 Release Notes)
  • Solr 4.x, 3.x and 1.4 users are strongly recommended to upgrade to a later version of Solr. If that is not possible, they should take steps to block access to the server or disable the ReplicationHandler if not in use.

Note: Even SolrCloud users who are not using "legacy" Index Replication can be affected by this vulnerability. SolrCloud uses the ReplicationHandler internally, so SolrCloud users must keep the ReplicationHandler configured for continued operation of their Solr system.

Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk