Subject: [DNSOP] DNS pinning, anti-pinning and rebinding in DNSOP?

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Aug 2007 12:35:05 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Aug 2007 15:09:52 +0300 (EEST)

> violation of the DNS protocol). Advices?

Thanks for the interesting link.  This certainly shows that "use 
hostnames everywhere" idiom that the IETF has been repeating doesn't 
quite work as intended in the real life :-)

I wonder if the authors and vendors have considered if there are 
conseuqences for IPv4/IPv6 dual-stack operation where a standard 
practice is to provide multiple IP addresses under a single name.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Aug 2007 15:09:52 +0300 (EEST)

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 8 Aug 2007 14:21:49 +0200

Pekka Savola (pekkas) writes:
> 
>  Thanks for the interesting link.  This certainly shows that "use hostnames 
>  everywhere" idiom that the IETF has been repeating doesn't quite work as 
>  intended in the real life :-)

    Yes it does, it's not a bug, it's a feature.  It does exactly the right
    thing from the point of view of the implementation.  This is, in my
    opinion, the same problem scope as IDN homographic attacks, just one
    level of interaction (App <-> DNS, as opposed to User <-> APP).

    Section 5.2 of the paper suggests:

"Instead of trying to prevent a host name from rebinding 
 from one IP address to another -- a fairly common event --
 a different approach to defending against rebinding is to 
 prevent the attacker from naming the target server."

    IMHO the problem is there, i.e.: fix the application (browser
    javascript/sandboxing mechanisms), don't blame DNS for doing exactly
    what it was intended to do.

    It'd be even more stupid to look up IPs once and stick to those
    during the life of the application (== execution of the Flash code,
    or JS code, which can be anything from a few milliseconds to several
    hours).  The problem is the same as for traditional (read: standalone)
    applications which lookup IPs once and never look them up again.

    Other solutions are outlined such as blocking direct DNS queries to
    the outside world, and/or using DNS software that refuses to relay
    replies containing internal IP addresses from the outside.  That's
    just spoofing protection at the DNS level.
    
    The section on Host Name authorization is interesting, but it's
    a hack.

---

From: Phil Regnauld <[email-masked]>
Date: Wed, 8 Aug 2007 14:21:49 +0200

---

From: Dean Anderson <[email-masked]>
Date: Wed, 8 Aug 2007 16:04:37 -0400 (EDT)

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

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Wed, 8 Aug 2007 16:04:37 -0400 (EDT)

--Dean