I’m sure virtually all of our readers are aware of the patch that has been released for Drupal yesterday. In case you’ve been on a remote island, all versions of Drupal (6, 7 and 8) were vulnerable to a critical security vulnerability that allows an attacker remote code execution.

Since Drupal is pretty popular, there are probably couple of millions of web sites that are vulnerable to this vulnerability (one would hope that a large number has been patched).
The patch itself is relatively simple: early when processing requests (in the preHandle() function), in the core/lib/Drupal/Core/DrupalKernel.php file, a call to the RequestSanitizer::sanitize method (a newly added method) has been added, as shown below:

The RequestSanitizer::sanitize method is defined in a new file, core/lib/Drupal/Core/Security/RequestSanitizer.php – it’s a simple method that takes the incoming request created by the Symfony PHP framework (that is used by Drupal). The sanitize() method then sanitizes received parameters in GET (query string), POST (body) and cookie parameters.

For each of these, the stripDangerousValues() function cycles over all keys and checks if the key is set to any value, if it’s in a whitelist or if the key’s name starts with a #. We can see this code below:

If the key’s name matches any of the cases above, it is deleted (unset()). The function additionally detects arrays and treats them the same way by recursively calling itself.

This is actually a feature supported by PHP: it supports the [] syntax for passing parameters to the application. For example, the following request:

https://isc.sans.edu/core/core.api.php?sans[]=1&sans[]=2&sans[]=3

Will cause PHP to create an array out of the supplied parameters. Now when the application retrieves $_GET[‘sans’] the result will actually be an array(1, 2, 3). Additionally, in Drupal, the # character has a special meaning: it is a reserved character used by the form API. Combining these two facts probably allows exploitation of the RCE vulnerability.

At this point in time there are no exploits abusing this vulnerability in the wild (at least no exploits that we know about) – which gives you a bit more time to patch, if you haven’t already.

Also, I’ve seen many people calling Drupal for missing sanitization like it’s pre-2000. There are quite a bit of security controls in Drupal and it would not be really fair (in my opinion) to say that it’s completely insecure. Additionally, what I like about the patch is that it has been added early enough in the request processing path, so it is more difficult to figure out how to exploit the vulnerability, which means that it will take attackers more time to come up with a running exploit. Of course, once someone publishes this, you better be at the last (patched) version.

Time to setup those honeypots – let us know if you have more information about the vulnerability or attacks abusing it.

--
Bojan
@bojanz
INFIGO IS