DNS rebinding: prevention?

[Mordechai T. Abzug]

On Tue, Aug 07, 2007 at 03:00:43PM +1000, Mark Andrews wrote:

> 	It's also not as straight forward as people seem to think.

> 	You would need lots of exception processing which would be
> 	a combination of name and/or address and/or tsig pairs.

Both of my posts so far have said that an exception mechanism would be
needed.  That said, bind already has a lot of ACL-related plumbing.
One way to implement this would be a global ACL option like
"allow-external-pointing-to-this" that defaults to "any".  Each zone
also takes a (possible) "allow-external-pointing-to-this" ACL that
overrides the global option.  Each "allow-external-pointing-to-this"
ACL is a regular bind ACL with addresses, TSIGs, or whatever.

If there is a known external name without a unique external bind ACL
(i.e. address and/or TSIG) that identifies, and there is no existing
zone statement for it, and you want to consider it internal, create a
zone stanza for that zone that is a "type forward" and repeats the
global forwarding policy.  It may even be desirable to create a new
zone type for "inherit", which is semantically equivalent to "type
forward" with the same forwarding policy as the global forwarding
options, just so one can set other options (such as
"allow-external-pointing-to-this") more easily.  [I'd like "type
inherit" in general!]

Then, for all incoming queries:

(0) perform traditional security checks before proceeding.  If they
    pass, proceed to next step.

(1) Can the query be answered from the authoritative zones or the
    cache?  If yes, "allow-external-pointing-to-this" does not matter,
    and follow traditional rules.  Otherwise, proceed to next step.

(2) Does the queried hostname belong to a configured "zone" statement?
    If yes, follow traditional DNS rules.  Otherwise, proceed to next
    step.

(3) get an answer following traditional rules, and when the answer
    comes back, check to see if relevant rdata response fields for the
    given record type (i.e. A, NS, AAAA, CNAME, PTR, MX, SRV, etc.)
    match configured forward or reverse zone.  It not, it's OK, and
    return the response.  Otherwise, proceed to next step.

(4) What IP responded?  Check "allow-external-pointing-to-this" ACL
    for the zone that is pointed at, or if it doesn't exist, the
    global "allow-external-pointing-to-this" option.  If allowed,
    respond normally.  Otherwise, give an appropriate error response
    to the requestor.

In a forward-only architecture where the upstream servers are trusted
to hold some "internal" DNS data, the downstream servers should not
bother to implement "allow-external-pointing-to-this", and the
upstream servers should implement "allow-external-pointing-to-this".
In a forward-only architecture where the forwarding server is entirely
external, the "allow-external-pointing-to-this" has to be implemented
on the downstream server.

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.

I don't think this will be trivial, but it doesn't seem that complex,
either.  Then again, I don't hack bind code.  ;)

Note that this assumes that all zones on a cache are "internal" zones.
This is probably a valid view for corporations, government agencies,
small businesses, non-profits, and most other organizations.  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.

Also note that this doesn't preclude having secondary/slave zones for
peer companies/agencies/organizations where the peer zones are
untrusted.  If this runs on the same hardware as the caching DNS, the
externally-visible DNS can be in its own view.

It may also be desirable to have a per-zone option for "external", to
mean that the zone is not trusted to point at other internal zones
even though it is locally configured.

> 	All of this to "fix" a flawed security model.

In part, yes, the immediate issue is someone else's problem.  That
said, it's a lot easier to fix it here, definitively, than continue to
use patchwork solutions elsewhere.

In part, this is a DNS security flaw, too.  Why can external entities
point their RRs at my names and IP address space and try other novel
forms of DNS-based attack against my hosts?  What is the next problem
that will exploit this?  Even aside from this particular issue, my
internal DNS server should be configurable to not trust external
servers that want to say things about my names and my IPs.  I know
security people who were bothered by this before they learned about
DNS rebinding.  DNS rebinding proves that they were right.  This is a
flaw in the DNS specification.

Similarly, if one has a policy (not security at all!) that all
internal IPs must be hosted on organizational DNS, in the current
world, it's technically feasible for "rogue" internal groups to bypass
this policy.  The rogues just register external DNS names pointing at
internal servers.

So even if this particular issue gets fixed at the browser, it would
be nice for bind to provide a mechanism to deal with the more general
problem.

- Morty