bugtraq - Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <489D5555.1020200@links.org>
Date: Sat, 09 Aug 2008 09:29:09 +0100
From: Ben Laurie <ben@...ks.org>
To: Hal Finney <hal@...ney.org>
Cc: benl@...gle.com, bugtraq@...urityfocus.com,
	cryptography@...zdowd.com, full-disclosure@...ts.grok.org.uk,
	general@...nid.net, security@...nid.net
Subject: Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

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.

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

b) 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