Note: Since this generally seems to be at worse a DoS vector, cleared by the security team to be public/normal bug fix

A security audit of a customer site found that for Drupal sites integrated with a Solr back-end that supports EDismax as the default query parser (generally Solr 3.x or 4.x, or 1.4.x if patched and custom-built), the user could enter "local" parameters in the search box and these override the ones passed to Solr by the module.

A simple example of why that could be a problem is a DoS attack that lets the user increase the number of results returned from 10 to 10000 causing either Solr or the webserver to have performance issues, and possibly making PHP go OOM.

This issue likely also affects search_api_solr module.

Speaking to the Solr maintainers, this is not really an advertised feature of the EDismax query parser (though looking at the code it may be an expected feature from the way the code works), which is suggested as suitable for direct user input. However, the docs do seem to suggest it's expected: http://wiki.apache.org/solr/ExtendedDisMax#Parameters

An example mitigation would be this change:

diff --git a/apachesolr_search.module b/apachesolr_search.module
index 51dc6d4..7003cd8 100644
--- a/apachesolr_search.module
+++ b/apachesolr_search.module
@@ -125,6 +125,13 @@ function apachesolr_search_search($op = 'search', $keys = NULL) {
       $filters = isset($_GET['filters']) ? $_GET['filters'] : '';
       $solrsort = isset($_GET['solrsort']) ? $_GET['solrsort'] : '';
       $page = isset($_GET['page']) ? $_GET['page'] : 0;
+
+      // Don't allow local params to pass through to EDismax from the url.
+      if ($keys) {
+        $keys = preg_replace('/{![^}]*}/',' ', $keys);
+        // For good measure - disarm any that we missed in the regex.
+        $keys = str_replace('{!',' ', $keys);
+      }
       try {
         $results = apachesolr_search_execute($keys, $filters, $solrsort, 'search/' . arg(1), $page);
         return $results;
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pwolanin’s picture

Status: Active » Needs review
FileSize
1.85 KB

an alternate fix that avoids touching user input:

pwolanin’s picture

FileSize
2.36 KB

Here's one that actually works with the spellcheck.

However, I'm not sure I like the added complexity here - maybe worse DX too.

pwolanin’s picture

FileSize
735 bytes

Here's a simplified version of the one above for 7.x

pwolanin’s picture

Version: 7.x-1.x-dev » 6.x-3.x-dev
Status: Needs review » Patch (to be ported)
pwolanin’s picture

Status: Patch (to be ported) » Needs review
FileSize
739 bytes

Status: Needs review » Needs work

The last submitted patch, 1966044-5-D6.patch, failed testing.

pwolanin’s picture

Status: Needs work » Needs review

#5: 1966044-5-D6.patch queued for re-testing.

pwolanin’s picture

Version: 6.x-3.x-dev » 6.x-1.7
Status: Needs review » Patch (to be ported)

committed. needs 6.x-1.x

pwolanin’s picture

Version: 6.x-1.7 » 6.x-1.x-dev
Status: Patch (to be ported) » Needs review
FileSize
749 bytes
pwolanin’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Needs review » Needs work

looks like a leading {! causes a parse error - maybe should go back to the extra stomp in the original post

pwolanin’s picture

Status: Needs work » Needs review
FileSize
906 bytes
pwolanin’s picture

Version: 7.x-1.x-dev » 6.x-3.x-dev

committed

pwolanin’s picture

also applied to 6.x-3.x with fix of + to *

pwolanin’s picture

Version: 6.x-3.x-dev » 6.x-1.x-dev
Status: Needs review » Fixed
FileSize
866 bytes

committed this to 6.x-1.x

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.