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: Ben Laurie <ben_at_nospam>
Date: Sat Aug 09 2008 - 08:29:09 GMT
To: Hal Finney <hal@finney.org>


Hal Finney wrote:
> 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.

Yeah, I considered this scheme. The problem is that it doesn't really help the relying parties, who can still be fooled into believing an existing user is returning (or a new one is arriving) from the original site. This is particularly a problem for Sun's OpenID Provider, which makes the additional assertion (out of band) that the user is a Sun employee. So, anyone can become a Sun employee, as of a few days ago.

This is why the lack of CRL checking in OpenID libraries is an issue.

> 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.

In general, DNS is not fixable without deploying DNSSEC.

  1. The current "fix" just reduces the probability of an attack. If attacker and victim have sufficient bandwidth, it can still be done in under a day.
  2. There are many scenarios, mostly revolving around the use of wireless hotspots, where users are easily fooled into using a malicious DNS provider.

So, DNS patching is not, IMO, the real answer to this problem. Of course, the second scenario has been around forever, but is conveniently ignored when explaining why CRLs are not necessary (and all other things that rely on perfect DNS). All that's happened recently is we've made people who are sitting still just as vulnerable as travellers.

But increasingly we are all travellers some of the time, from a "how we get our 'net" POV. We really can't ignore this use case.

Cheers,

Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/