DNS rebinding: prevention?

[Mordechai T. Abzug]

On Wed, Aug 08, 2007 at 05:58:07AM +0200, Ralf Weber wrote:

> I said that I don't see it happen any time soon, however I doubt
> that your solution is done by only some config changes, it at least
> requires some code changes to a name server software.

Oops.  Yes, sorry, wasn't clear -- both a DNS server config change and
a DNS server code change would be required.

> As said it isn't an DNS issue. The issue is with the protocol
> designers.

I submit that we have an inherently flawed model if I, as a sysadmin,
cannot control my own DNS servers to prevent them from passing
external entities' RRs that point at my own names and IPs.  This is an
enabling vulnerability -- it's not a direct problem by itself, but it
takes one other protocol designer that doesn't understand DNS to do
something stupid, and it becomes a problem.

This is actually the second known time that DNS rebinding has been a
problem.  And who knows if there aren't other such problems that
haven't been noticed?  So are we going to learn from history and fix
this at the DNS layer, or wait until the next problem?

[Note: we can really only fix this for externals pointing to internal
names/IPs, not for externals pointing to third-party names/IPs.  So
the proposed solution is a complete fix for part of the problem, but
another part of the problem remains.]

> The next vulnerability may be also in the code that was needed
> introduce that feature.

Yes, there could always be a bug in introduced code, but we don't sit
paralyzed and afraid to introduce new features because of that
possibility.

> Well so you are running an server that works as both an authoriative
> server and an iterative resolver, while this may be common in an
> enterprise environment, it is not in a service provider environment.
> A service provider may have two customers where a web site is
> transferred between them while it also may be the one customer
> attacking another. How do you judge which is which?

I discussed this in a previous email:

http://groups.google.com/group/comp.protocols.dns.bind/msg/2895c1c176e37ca0

Quoting from there:

  In a "view" environment, each view should consider its collection of
  zones to be independent of other zone collections.  So if view A
  contains zones X and Y, and view B contains zone Z, it's OK from A's
  perspective for X to point to Y, but not for Z to point to Y.

  ...

  Service providers running DNS servers for multiple entities, each of
  which does not trust the other, will have a more complex
  perspective.  The cleanest way to handle this would be to split the
  different entities into separate views -- which is probably this
  best way to handle this architecture even without this issue.
  However, I cannot personally speak to the service provider
  environment.

As I said there, I think this can be handled by making the boundary
for external DNS be views, and splitting customers into different
views.  However, I personally have never worked in a service provider
environment, so I'm not sure.  That said, I don't think that the
difficulties of doing this for service providers should stop us from
doing this for the many other common scenarios such as corporations,
government agencies, non-profits, SOHOs, etc.

- Morty