Drupal Disputed CVE Five Year Tempest – Open Source Security Shortfall?

Question

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?

Answer 1

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.

Answer 2

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.