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

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

From: Hal Finney <hal_at_nospam>
Date: Fri Aug 08 2008 - 22:14:46 GMT
To: benl@google.com, bugtraq@securityfocus.com, cryptography@metzdowd.com, full-disclosure@lists.grok.org.uk, general@openid.net, security@openid.net

[I feel a little uncomfortable replying with such a wide distribution!]

Getting browsers, or OpenID installations, to check CRLs or use OCSP to check for freshness is likely to be slow going. At this point I think the momentum still favors fixing the remaining DNS systems that are vulnerable to cache poisoning. This turnkey-MITM bug makes OpenSSL bad certs far more exploitable, as Dan Kaminsky pointed out in his report. OpenID is just one example of many where this is going to keep happening as long as DNS is unpatched.

I thought of one possible mitigation that can protect OpenID end users against remote web sites which have not patched their DNS. OpenID providers who used weak OpenSSL certs would have to change their URLs so that their old X.509 CA certs on their old URLs no longer work on the new ones. This will require all of their clients (users who log in with their OpenID credentials) to change their identifiers. DNS based MITMs will not be able to forge messages related to the new identifiers.

Customers can be alerted to this requirement as soon as they log in to a web site (relying party) whose DNS is NOT hacked; the redirection to the OpenID provider will give opportunity to notify the customer of the name change. Making this change may be somewhat inconvenient, but since OpenID is a relatively new standard, at least it is easier than would be the case with a more established protocol.

In the other direction of attack, the end user's DNS is poisoned and he gets redirected to a bogus site in place of the OpenID provider; that site is then able to provide a valid SSL certificate due to the OpenSSL weakness, thereby stealing whatever authentication credentials the user normally sends to his OpenID provider. This is one instance of the general attack where a user is DNS-misdirected to a bogus copy of a secure site which unfortunately used weak OpenSSL based certs.

Again, I see fixing the DNS as the path of least resistance here, especially so since the end user is the one bearing most of the risk, typically DNS is provided by an ISP or some other agency with a formal legal relationship, and there is the possibility of liability on the part of the lax DNS provider. Hopefully we will continue to see rapid uptake of the DNS fix over the next few weeks.

That still leaves weak-cert OpenID users vulnerable to DNS-unpatched service providers (OpenID relying parties), and that is where my proposed mitigation above comes in. By renaming its URLs, an OpenID provider who had the misfortune to create a weak OpenSSL cert (through no fault of its own) can save its end users considerable potential grief.

Hal Finney

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