Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Can someone add context to the subject issue? At first glance it appears to me this issue represents a fundamental shortfall in the forces encouraging secure coding in open source development. Is that the case and/or is this example common or a rare outlier?

I note that CVE-2007-6752 released on 28 March 2012 listed as an under review CSRF vulnerability has the status:

** DISPUTED ** Cross-site request forgery (CSRF) vulnerability in Drupal 7.12 and earlier allows remote attackers to hijack the authentication of arbitrary users for requests that end a session via the user/logout URI. NOTE: the vendor disputes the significance of this issue, by considering the "security benefit against platform complexity and performance impact" and concluding that a change to the logout behavior is not planned because "for most sites it is not worth the trade-off."

In trying to get my head around the fact that the CVE dates to 2007 I found Red Hat carries a related bug report https://bugzilla.redhat.com/show_bug.cgi?id=807859 remarking that there is no upstream fix and “Eek. What a tempest…” That entry shares a link to five years of bug dialog within Drupal http://drupal.org/node/144538 that suggests the Eek comment is most appropriate.

Can someone enlighten me about the thinking behind the Drupal complexity trade-off response to an apparently acknowledged CSRF vulnerability? Is it just a simple case of “You can’t get there from here” limitation in a popular open source product? Does it matter or is this just a trivial issue I am misreading?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

As far as I can tell, this is a bogus bug report. I think the Drupal team is 100% in the right to dismiss and contest this "bug report". None of the alleged "vulnerabilities" seem like vulnerabilities to me. Just claiming that something is a vulnerabilities doesn't necessarily make it so.

The reporter alleges a number of problems:

  1. Allegation: if the attacker learns the CSRF token, he can defeat the CSRF defense. Well, duh. That's how CSRF tokens work. It's not a vulnerability. When we use CSRF tokens, we design the system to avoid revealing the token to attacker. If the reporter found some way that an attacker could learn the CSRF token, we could discuss it, but as it is, the reporter has nothing.

  2. Allegation: the logout method is not protected by a CSRF token, so an attacker could log an administrator out. This claim does not appear to be contested on the facts, so I will assume it is correct. However, there is no obvious security consequence or danger from being able to forcibly log out an administrator. There are also other ways to forcibly log out a user, in every web application ever built, e.g., by exceeding capacity limits on the browser cookie jar.

  3. Allegation: Drupal doesn't consistently check the referer header on all requests. That's not a security flaw. The Referer header should not be used for security purposes, as attackers can spoof it or force it to be omitted. The reporter does not allege any harm that is caused by this property of Drupal.

  4. Allegation: Drupal does not distinguish POST vs GET methods. This is probably a case of poor implementation practice, but there is no security consequence identified by the reporter, and no obvious harm.

See also the Drupal group's official response.

Basically, I think the original report should be ignored and treated as invalid, for failure to allege a valid security vulnerability. I don't see any shortfall, fundamental or otherwise, in the security of open source. Actually, I think it is to the Drupal team's credit how carefully they responded to the allegations.

share|improve this answer
    
+1 for link to group official response. My question just focused on "Analysis of 2.2 Poor Session Checking (CSRF to Force administrator logout)" part which is addressed but somewhat buried in the rebuttal. I'll tease out claims of working attacks against response that killing session is only impact and follow up. Thanks. –  zedman9991 Mar 29 '12 at 19:45
1  
2a. a force logout is an attack on Availability and many would consider this a security issue. Obviously it is a nuisance attack, having less impact than Confidentiality and Integrity attacks in most cases. 2b. overflowing cookies requires the ability to get cookie write access into the site or a related domain, usually through cross-site-scripting, which is not a necessary part of this attack. –  bobince Mar 30 '12 at 10:47
1  
4. There would be security impact if the XSRF token were included in a GET URL, because it's possible for URLs to leak through various means (commonly referrers). So at the moment there's not an issue, but with the suggested solution with logout/token in the path there could be. Clearly this should have been POST-only (styled button instead of link) all along, for good practices and usability. –  bobince Mar 30 '12 at 10:49
1  
@bobince, 2a. It's not a very effective attack, because the admin can just log in again. 2b. No, you are wrong. There is no such requirement. Go read the discussion I linked to. 4. But that's not how Drupal works, so your hypothesized vulnerability is only hypothetical. I do agree that logout (and other actions with a side effect) should have been POST-only, and that's something they ought to fix -- not because it is an exploitable vulnerability, but because it is bad practice. –  D.W. Mar 30 '12 at 17:00
add comment

Security is always a tradeoff. To gain additional security, you usually have to sacrifice convenience, performance, or some other cost. In this case, the Drupal team is arguing that the incremental security benefit is so inconsequential that it doesn't warrant the cost of implementation.

From reading the exploit report, it appears that there are a few "exploits" reported. One indicates that if a person attacks from a man-in-the-middle position or from a process on the victim's own computer, he can leverage that position to perform an XSRF attack. It can be argued that such an attacker must have so much access to mount such an attack that he isn't gaining anything that he doesn't already have.

Another attack listed says that the attacker can create a logoff form which, if submitted by the victim, will log the victim off. The drupal team argues that because the victim actually has to POST a logoff form (which requires deliberate action), and because the "payload" of the attack is to simply log the victim off, and since fixing this issue will break most existing themes, then the security benefit gained does not warrant the mess that fixing it would cause.

Finally, the report says that while the forms have appropriate XSRF checking, the interface does NOT do HTTP-Referrer checking on all forms. And therefore, if the attacker was somehow able to capture the XSRF token, he could use it mount an XSRF attack from another domain. The drupal team argues that the whole point of the XSRF token is to prevent this type of attack even without Referrer checks. They argue that adding a Referrer check does not actually add more security, but it does lower performance and browser compatibility. Therefore, they argue, this is a non-issue and not worth addressing.

share|improve this answer
    
+1 thanks for drilling down –  zedman9991 Mar 29 '12 at 16:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.