[OpenID] OpenID/Debian PRNG/DNS Cache poisoning advisory

Fri Aug 8 14:54:08 UTC 2008

On Fri, Aug 8, 2008 at 1:25 PM, Peter Williams <pwilliams at rapattoni.com> wrote:
> moral: op should not be relying on assurances of commodity, software crypto, given a ttp role. Duh.
>
> The argument stuck me as interesting and yawn, at the same time. The construction was interesting (fail to setup a pki ciphersuite ssl endpoint once, and the https assurances of its domain name are compromised for the life of the valid cert). But, at the same time, fail at the prng stage of keygen of a ttp, then there is an expected cascade of vulnerabilities and actual exposures. Fail to check endpoint cert chain *element* status (and msft cryptoapi checks its hosts reliance on ssl crypto-provider's certs in interesting ways, note, using ocsp), one was failing anyways to engage in the practice of defence in depth - which assumes countermeasures fail, and barriers must be erected to specifically contain cascaded failures of critical infrastructures based on TTPs.

Indeed, and this is why I single out CRL checking as a mitigation.

> One can propose greater impact, too, if one makes a few more quite realistic assumptions. If the expiry date of certs is not checked, or the checking hosts time source is not trustworthy or has been intentionally polluted, then the https endpoint is contaminated "forever". But, my argument hardly "resonates". Its just another projection of a cascaded failure path.
>
> One interesitng note perhaps. Fips 140-2 level 3 devices providing pkcs11 services over ip are usually designed to require ssl3 - which guards access to the communication channel to the provider by clients (with layer 4 client certs, and server trust stores). Trusted console access (keyfill) is enforced to loadkey into the trust stores of the trusted cryptodevice, and use of ip addresses vs domain names when minting certs is advised.) No revocation via crl or ocsp is (or at least "was" 2 years ago) used in this layer 4 application of ssl (and that was "ssl", not "https", note), since the assurances derive from the key loading process, key wrapping primitives in the assured ciphersuites, and the tagged keying material design concept (preventing cleartext release of key or keying material through the crypto boundary).

So if I'm understanding correctly, should such a device prove to not
be secure in some way, any RP is screwed?

>
> -----Original Message-----
> From: Ben Laurie <benl at google.com>
> Sent: Friday, August 08, 2008 5:58 AM
> To: bugtraq at securityfocus.com <bugtraq at securityfocus.com>; security at openid.net <security at openid.net>; OpenID List <general at openid.net>; cryptography at metzdowd.com <cryptography at metzdowd.com>; full-disclosure at lists.grok.org.uk <full-disclosure at lists.grok.org.uk>
> Subject: [OpenID] OpenID/Debian PRNG/DNS Cache poisoning advisory
>
>
> 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 at openid.net
> http://openid.net/mailman/listinfo/general
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>