|Main Archive Page > Month Archives > full-disclosure-uk archives|
Security Advisory (08-AUG-2008) (CVE-2008-3280)
Ben Laurie of Google's Applied Security team, while working with an external researcher, Dr. Richard Clayton of the Computer Laboratory, Cambridge University, found that various OpenID Providers (OPs) had TLS Server Certificates that used weak keys, as a result of the Debian Predictable Random Number Generator (CVE-2008-0166).
In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and the fact that almost all SSL/TLS implementations do not consult CRLs (currently an untracked issue), this means that it is impossible to rely on these OPs.
In order to mount an attack against a vulnerable OP, the attacker first finds the private key corresponding to the weak TLS certificate. He then sets up a website masquerading as the original OP, both for the OpenID protocol and also for HTTP/HTTPS.
Then he poisons the DNS cache of the victim to make it appear that his server is the true OpenID Provider.
There are two cases, one is where the victim is a user trying to identify themselves, in which case, even if they use HTTPS to "ensure" that the site they are visiting is indeed their provider, they will be unable to detect the substitution and will give their login credentials to the attacker.
The second case is where the victim is the Relying Party (RP). In this case, even if the RP uses TLS to connect to the OP, as is recommended for higher assurance, he will not be defended, as the vast majority of OpenID implementations do not check CRLs, and will, therefore, accept the malicious site as the true OP.
Mitigation is surprisingly hard. In theory the vulnerable site should revoke their weak certificate and issue a new one.
However, since the CRLs will almost certainly not be checked, this means the site will still be vulnerable to attack for the lifetime of the certificate (and perhaps beyond, depending on user behaviour). Note that shutting down the site DOES NOT prevent the attack.
Therefore mitigation falls to other parties.
Normally, when security problems are encountered with a single piece of software, the responsible thing to do is to is to wait until fixes are available before making any announcement. However, as a number of examples in the past have demonstrated, this approach does not work particularly well when many different pieces of software are involved because it is necessary to coordinate a simultaneous release of the fixes, whilst hoping that the very large number of people involved will cooperate in keeping the vulnerability secret.
In the present situation, the fixes will involve considerable development work in adding CRL handling to a great many pieces of openID code. This is a far from trivial amount of work.
The fixes will also involve changes to browser preferences to ensure that CRLs are checked by default -- which many vendors have resisted for years. We are extremely pessimistic that a security vulnerability in OpenID will be seen as sufficiently important to change the browser vendors minds.
Hence, we see no value in delaying this announcement; and by making the details public as soon as possible, we believe that individuals who rely on OpenID will be better able to take their own individual steps to avoid relying upon the flawed certificates we have identified.
OpenID is at heart quite a weak protocol, when used in its most general form, and consequently there is very limited reliance upon its security. This means that the consequences of the combination of attacks that are now possible is nothing like as serious as might otherwise have been the case.
However, it does give an insight into the type of security disaster that may occur in the future if we do not start to take CRLs seriously, but merely stick them onto "to-do" lists or disable them in the name of tiny performance improvements.
There is no central registry of OpenID systems, and so we cannot be sure that we have identified all of the weak certificates that are currently being served. The list of those we have found so far is:
 There are ways of using OpenID that are significantly more secure
than the commonly deployed scheme, I shall describe those in a separate article.