what about this D7.12 exploit ?

It's bogus except for point 2.2. The form_token is bound to a particular session. As long as the token remains a secret, there's no exploit possible. The token can only be obtained if there's another vulnerability (XSS), which is why we have lots of code in Drupal to prevent XSS.
In case of MiTM I recommend that the attacker extracts the admin pwd or session id and does modifications himself instead of the round-about CSRF.

Point 2.2 deals with the logout CSRF which is a widely known and minor (though annoying) issue. See #144538: User logout is vulnerable to CSRF for a discussion. POST vs GET doesn't' really matter here, as an iframe post to the logout URL would have the same effect as a GET request from an image embedded in the 'attack' page.

The HTTP_REFERER check recommendation is ridiculous.

I have read this exploit and in my opinion it is right.

Http_Referer checking is a primary element to prevent CSRF exploit. I would recommend to Heine to read OWASP doscumentation about it https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Pr...

Point 2.2 If you check Http_referer you could not use form_token ad solve your CSRF "minor" (I think Hine did not perform really an Man in the middle attack) vulnerability.

Point 2.1 I verified that Drupal has problems described in above advisory because did not correctly chech "form_buid_id" parameter. Question for Heine: why you introduced this parameter if you don't use it?
"form_token" parameter: also this parameter has problems because it should be unique for any operation, instead is the same for similar operations in the same session.

Can an attacker use this exploit to gain access to the system? As descibed in the advisory these vulnerabilities can exploited by an internal attacker (did you think that internal attackers are not a problem? ok then your Drupal cms is not vulnerable) which is able to sniff form_token parameter and so create a new Drupal administrator account.
Any external attacker that controls an internal client become an internal attacker.

When you perform an Man in the Middle attack you can simply redirect all the traffic to an attacker machine and from the attacker machine redirect the traffic to oroginal destination without the networks know about it. This is passive method and it is very SILENT and, most of all, is very simple to perform.
Drupal should not allow this.

Dear Heine,
You should use both token check and http_referer check. Sure, if could use only token check but you need to secure it and improve form_token generation in order to make it unique for any operations.
You say that http referer check can be bypassed by XSS. Sure but I don't think that latest Drupal release (7.12) is vulnerable to XSS. So http_referer check is good solution to avoid CSRF vulnerability. Most of all because in the page you link "dumm" says that "We can't add a token....."

You say that http_referer is not always included in the request: sure because there are simply hacks to not send http referer in http request (for example using ) but when you perform http refere check,when you don't receive http_referer you should discard that request because it means that someone is trying to spoof http_referer. Simple, not?

Sure you can improve security with https (note that Drupal defualt installation uses only http) but if you correct form_token logic generation and introduce http_referer checking you will make (almost) impossible to exploit Drupal.

An official response to this issue is now posted at http://drupal.org/node/1475530

Some more specific analysis and details are here: http://groups.drupal.org/node/216314

Security Drupal's analysis (http://groups.drupal.org/node/216314) is wrong for the following motivations:
1) why do you inserted "Suggested mitigation steps" if you think isn't a real vulnerability?
2) do you know what a POC means? It is ridiculous that the exploit doesn't work because "new_admin.com" is not a valid hostname. IT IS only A POC for demonstration purpose and, normally, to avoid lamer damage in the POC voluntarily the exploit has some mistake.
3)A site cannot be vulnerable to MITM. Is the network that is vulnerable if isn't implemented "Port Security" on network switch or if there aren't IDS/IPS devices to detect and prevent man in the middle.
4) You have some anomalies in "form_token" and "form_build_id" even if you don't want to admit it.
5) A CSRF attack is more silent if you allow to send POST request instead of GET request. I think that this is the meaning.
6) Simple Http_Referrer check would allow to avoid "force logout" CSRF which could aid an hacker to sniff user and password during a MITM

Also Heine's consideration about XSS are wrong. Is ridiculous that Drupal doesn't perform http_referrer check as XSS could allow to bypass it. This argument is like saying "I don't put the doors at home as could be some thieves able to open them"

MITRE CVE Numbering Authority assigned CVE-2007-6752 for "force user/logout" (sections 2.2, 3.2 of my Drupal 7.12 CSRF Advisory).

Furthermore MITRE CVE Numbering Authority, considers that:

. Sections 2.1 and 3.1 – Poor Session Checking (CSRF to change any Drupal settings) – would be a Drupal’s “Security Improvement”.
. Section 2.3 – Poor Session Checking (POST and GET method) – and section 2.4 - Poor Session Checking (Http Referer) - would be Drupal’s “Potential Security Improvements”.