Drupal Disputed CVE Five Year Tempest – Open Source Security Shortfall?
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:
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.
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.
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.
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.
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.