A large part of the fix addresses multiple vulnerabilities due to optimistic cross-site request forgery protection. The company explained in its advisory that Drupal's form API has built-in cross-site request forgery (CSRF) validation, and also allows any module to perform its own validation on the form.
“Given that the CSRF protection is an especially important validation, the Drupal core form API has been changed in this release so that it now skips subsequent validation if the CSRF validation fails”, it said.
This vulnerability is mitigated by the fact that a form validation callback with potentially unsafe side effects must be active on the site, and none exist in core. However, being open source, Drupal has been made vulnerable thanks to several popular contributed modules which allowed remote code execution.
For instance, Debian, a Linux-based open-source project, issued its own mitigation advice. “In order to avoid the remote code execution vulnerability, it is recommended to create a .htaccess file (or an equivalent configuration directive in case you are not using Apache to serve your Drupal sites) in each of your sites' files directories (both public and private, in case you have both configured)”, it said.
Drupal also added 'defense in depth' protection to prevent script execution by placing a .htaccess file into the files directories that stops execution of PHP scripts on the Apache web server - a protection that is only necessary if there is a vulnerability on the site or on a server that allows users to upload malicious files. However, the configuration in the .htaccess file did not prevent code execution on certain Apache web server configurations. The new release includes new configuration to prevent PHP execution on several additional common Apache configurations, but if users are upgrading a site and the site is run by Apache, they must fix the file manually.
Multiple vulnerabilities also exist in earlier versions of Drupal due to weakness in pseudorandom number generation (Form API, OpenID and random password generation). While the Drupal core directly used the mt_rand() pseudorandom number generator for generating security-related strings used in several core modules, the company discovered that brute force tools could determine the seeds making these strings predictable under certain circumstances.
Aside from these critical issues, the company uncovered a range of flaws that are not as far-ranging. For instance, it noted that an XSS vulnerability was found in the Color module, allowing a malicious attacker to trick an authenticated administrative user into visiting a page containing specific JavaScript that could lead to a reflected XSS attack via JavaScript execution in CSS. But the issue is mitigated by the fact that it can only take place in Opera through user interaction, and Internet Explorer under certain conditions.
There is also an issue with security token validation that is limited at best: if the caller does not make sure that the token is a string, an invalid token can get by. This vulnerability is mitigated by the fact that a contributed or custom module must invoke the token function with an argument that can be manipulated to not be a string by an attacker. But, there is currently no known core or contributed module that would suffer from this vulnerability.
There are two issues that require attackers to have specific administrative rights as well. Also in the XSS realm, non-updated versions allow image field descriptions that are not properly sanitized before they are printed to HTML. “This vulnerability is mitigated by the fact that an attacker must have a permission to administer field descriptions, for example the ‘administer taxonomy’ permission to edit fields on taxonomy terms”, the company said.
And finally, the Overlay module displays administrative pages as a layer over the current page (using JavaScript), rather than replacing the page in the browser window. As such, the Overlay module did not sufficiently validate URLs prior to displaying their contents, leading to an open-redirect vulnerability. “This vulnerability is mitigated by the fact that it can only be used against site users who have the ‘access the administrative overlay’ permission”, Drupal said.