This attack is at once more nefarious and less nefarious than article
documents.
It is more nefarious because many 'single site' schemes based on DNS
trust *.somedomain.tld as IP resources belonging to somedomain.tld. You
don't have to rebind even. The site www.attacker.com gives a script
that accesses www1.attacker.com, and www1.attacker.com has internal ip
addresses.
This is just another in a series of mistaken assumptions made about DNS,
and (mis) using DNS for trust purposes. In this case, the trust that the
same name resolves to (essentially) the same site is misplaced.
I think the correct solution for browsers is not to open additional
connections based on requests from external scripts, but to hold open
the original connection. External scripts should not be long lived, and
not longer than the original connection. If the script should live
longer, the original IP address should be used for connection, not the
DNS entry. The external script has no business outlasting the external
web server.
Cross Site Scripting is a serious and tough problem, and DNS rebinding
is a very small part of it. But the core of both problems is misplaced
assumptions of trust. The difficulty with XSS is that the malicous code
has access to the document model, and can alter other scripts, access
other fields, and do quite a lot. Infection is not just limited to
visiting a suspicious web site. The malicious code can be placed in your
own database, or some other sites database, and output to your browser.
It can be placed in pdfs, in anything that does javascript. And the
malicious code doesn't even have to exploit vulnerabilities in the local
javascript interpreter to steal passwords and other confidential
information (though, that's also possible).
I've been saying this for many years: Depending on DNS to determine
trust questions is always going fail or, as in this case, introduce
vulnerabilities.
This isn't a protocol problem or DNS operations problem.
Btw, 1-to-1 reverse DNS also won't prevent this attack. it should be
quite easy for such a script to spoof the reverse DNS response to the
browser, since it knows the timing of the request, and can see if the
response is the one "wanted". So it can "lather, rinse, repeat" with the
known timing and other information to get the desired response to the
browser. And spoofing may not be the only target of the 'lather, rinse,
repeat' process. DDOS is another possiblity. Indeed, the possibilities
are limitless.
--Dean
On Wed, 8 Aug 2007, Stephane Bortzmeyer wrote:
> I'm afraid that we will be sollicited one day or the other to write a
> RFC about DNS practices to limit rebinding? It seems trendy.
>
> Do note that many advices in "Protecting Browsers from DNS Rebinding
> Attacks" (http://crypto.stanford.edu/dns/dns-rebinding.pdf) belong in
> our perimeter (some remind me of
> draft-ietf-dnsop-reverse-mapping-considerations, some ask for a
> violation of the DNS protocol). Advices?
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www1.ietf.org/mailman/listinfo/dnsop
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
