The Drupal Security team has concluded that this does not constitute a valid vulnerability. The attack depends on a "Man In the Middle" attack or sniffing software, which is outside of Drupal and presents a much bigger risk.
The Drupal Security team provides an easy way to report issues by sending emails to email@example.com, and we will credit researchers with all issues they report in this manner. No formal report of this issue was filed directly with our team. We encourage all researchers to follow principles of responsible disclosure, and report directly to our team to ensure both that we can provide public credit for authentic vulnerabilities, and keep our users as secure as possible.
Please see the handbook page for the latest description of how to report security issues.
Our response to specific claims made in the report
Analysis of 2.1 Poor Session Checking (CSRF to change any Drupal settings)
The original report states:
This flaw can be used by [an] attacker [who] knows the values of "[form_build_id]" and "form_token" parameters (for example, an internal attacker performing a "Man in The Middle Attack" or an external attacker that controls an internal client by an client-side exploit, an external attacker that controls directly a Drupal admin by a client-side exploit and son on. There are many possibilities)
The described problem (using the same anti-CSRF token for every action on a site) is actually the exact recommendation by OWASP for how to protect against CSRF. OWASP refers to this as the Token Synchronizer Pattern and it is in use in many systems and on many websites today.
An attacker who is able to read the form_token and form_build_id values via "man in the middle" (MITM) or client-side exploit is presumed to also be able to read other unencrypted elements of the HTTP request such as the username, password and session ID. If they can read the session ID, then performing the exploit as described would be more work than simply stealing the session and directly performing attacks.
Even if there is a scenario where the Token Synchronizer Pattern isn't a sufficient protection, we believe Drupal is not vulnerable to the attack as described. After repeated attempts, we are unable to reproduce the supposed exploit and substantiate the claim that any combination of form_token and form_build_id can be used to submit any other form. We encourage other individuals to attempt to exploit the issue, and confirm or deny their ability to do so privately to the team.
The original title for issue 2.1 is "CSRF to change any Drupal settings." Given that the problem is only CSRF when another exploit like MITM or client-side control is in play, and given that it only affects the specific setting the user has visited, we find this title to be misleading.
Analysis of 2.2 Poor Session Checking (CSRF to Force administrator logout)
This is a known issue that, while annoying, doesn't represent a vulnerability since the only impact is being able to terminate a user's session. The community has debated the security benefit against platform complexity and performance impact in a public issue since 2007 and decided that for most sites it is not worth the trade-off. Users concerned about this issue are invited to work on the problem in that existing public issue.
Analysis of 2.3 Poor Session Checking (POST and GET method)
This doesn't appear to play any specific role in the attack.
Analysis of 2.4 Poor Session Checking (Http Referer)
Drupal is, by nature, a flexible system. A form or link that is located at one URL by the module developer may be moved to a different URL on a specific site by the site builder making the addition of referrer checking difficult. Since HTTP Referrer headers can be spoofed by user agents, and may not even be included in any particular request, these constitute an unreliable method for establishing the validity of requests. Given that these particular exploits require MITM or some form of client-side exploit, the HTTP referrer could also be altered via that mechanism, rendering this additional protection moot.
Analysis of 3.1 Demonstration code
The supposed demonstration code doesn't work for at least two reasons:
- The e-mail address uses a hostname of "new_admin.com," which doesn't pass Drupal's e-mail validation and is not a valid Internet domain name.
- The form_token is based on a hash of:
- the form_id value (a knowable string used to describe the form)
- the user's session ID
- a private key that is stored (by default) in the database, and
- a hash salt that is stored (by default) in Drupal's settings.php file, where other important values like the database credentials are stored.
Drupal's form API validates the form_token during submission of the form by comparing it to a hash for the same form_id. If the token doesn't validate, Drupal will stop form submission and respond with the error message "The form has become outdated. Copy any unsaved work in the form below and then reload this page."
Suggested mitigation steps:
Since the report requires a site be vulnerable to MITM or some other client-side control, the solution is to address those issues with the proper technology:
- HTTPS or other secured network access (e.g. a VPN) prevent MITM and sniffing
- Protect your site against cross site scripting via proper configuration and coding practices