Yuri, On Feb 16, 2007, at 2:37 PM, Yuri Demchenko wrote:
The question is how do they get the information that the data has been signed and the signatures validated. Since with this attack they'd be going through a compromised server, they lose. The only way out of that hole is if you run a local validating caching server and have appropriate (out-of-band validated) trust anchors configured and if you're running a local caching server, you're already not susceptible to the attack. I was thinking similar like home routers could have default configuration to use DNSSEC responses, and maybe in the future only DNSSEC.
Wouldn't this mean the nasty javascript merely updates the trust anchors to point to the bad guy's DNS server? That is, if the home user doesn't configure the password and the trust anchors are configurable on the router, the bad guys win. As was mentioned previously, this really isn't a DNS attack. It is a "exploitation of a default password" attack, so DNSSEC doesn't help.
As about trust anchors, in other security applications we looking now closely at the TPM (Trusted Platform Module)/TCG technology that provides hardware bound and hardware protected trust anchors.
This might work if it requires no end user interaction. Rgds, -drc