full-disclosure-uk August 2008 archive
Main Archive Page > Month Archives  > full-disclosure-uk archives
full-disclosure-uk: Re: [Full-disclosure] [OpenID] OpenID/Debian

Re: [Full-disclosure] [OpenID] OpenID/Debian PRNG/DNS Cache poisoning advisory

From: Gerald Beuchelt <beuchelt_at_nospam>
Date: Fri Aug 08 2008 - 13:17:51 GMT
To: Ben Laurie <benl@google.com>

We have been following up on Ben Laurie's advisory and have replaced the faulty certificate with a new one. In addition we created an advisory for our users that outlines some general precautions they should take:


While these measure cannot guarantee safety, they can help improving the situation. In addition, Robin Wilton has documented what happened here:


We are continuing to monitor the situation and might make additional changes to the service.

I would like to use this opportunity to thank Ben again for approaching us upfront and working with us while preparing his advisory.


Gerald Beuchelt

Ben Laurie wrote:
> 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.
> Attack Description
> ------------------
> 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
> ----------
> 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.
> 1. Browsers must check CRLs by default.
> 2. OpenID libraries must check CRLs.
> 3. DNS caching resolvers must be patched against the poisoning attack.
> 4. Until either 1 and 2 or 3 have been done, OpenID cannot be trusted
> for any OP that cannot demonstrate it has never had a weak
> certificate.
> Discussion
> ----------
> 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[1], 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.
> Affected Sites
> --------------
> 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:
> openid.sun.com
> www.xopenid.net
> openid.net.nz
> Notes
> -----
> [1] There are ways of using OpenID that are significantly more secure
> than the commonly deployed scheme, I shall describe those in a
> separate article.
> _______________________________________________
> general mailing list
> general@openid.net
> http://openid.net/mailman/listinfo/general

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/