DNS rebinding: prevention?
kcd at daimlerchrysler.com
Tue Aug 7 04:33:32 UTC 2007
I tend to agree. Trying to teach a firewall about all of the nuances of
parsing DNS replies is basically reinventing the wheel. We already have
a capable DNS-response-parser in the resolver, why not use it?
If a feature like this were implemented in BIND, though, I think the
"safe" thing to do, from a security standpoint, is to give a REFUSED
response if it were to otherwise give "forbidden" answers (address
records that can be legally dropped, e.g. from the Additional Section in
most circumstances, should simply be dropped). No way should BIND or any
other nameserver implementation give *partial* RRsets in responses, or a
NODATA response instead of an answerful response, just because the
administrator declared that certain addresses were "bad". While this is
"safe" from a security standpoint, it could easily break applications
and/or subsystems, turning otherwise-successful lookups into
irretrievably-failed ones. The documentation would need to clearly state
USE THIS WITH EXTREME CAUTION.
In my personal opinion, this "rebinding" problem is really the fault of
the crappy browser security model, not DNS, _per_se_, which has never
presumed that any address record is going to persist for any arbitrary
length of time. There's no "pinning" in DNS, never has been. So, any
such feature by BIND or other DNS implementations just buys some time
until the Security geniuses can redesign their deficient model.
Mordechai T. Abzug wrote:
> [resending from subscribed address]
> On Fri, Aug 03, 2007 at 09:50:28AM -0700, Chris Buxton wrote:
>> named would have to check the address of each A or AAAA record
>> coming from the outside to see if it refers to an internal address.
> Yes. And CNAMEs, too. Maybe NS records, SRVs, MXs, and some other
> record types I'm not thinking of. Which is OK -- bind already looks
> at the records at least a little bit, i.e. to cache them, to see if
> they match the query, etc. IME, bind runs at low CPU utilization on
> modern hardware for 10K users: there's definitely room for more work
> to be done by bind. And, of course, like any other feature, this
> should be able to be turned off for performance reasons or any other
> reason. "Any feature that cannot be turned off is indistinguishable
> from a bug."
>> This seems to be more a job for an application-level firewall that
>> can fully inspect the contents of DNS messages and filter based on
>> their contents.
> The DNS server is already parsing DNS replies and looking at them, to
> make sure that the query IDs match, that the answer is valid based on
> the query, to cache, etc. The DNS server is the expert on DNS. Why
> pass the buck to the firewall?
> Also, for large shops, where one hand doesn't know what the other is
> doing and there is a lot of specialization, I don't think you want the
> firewalls guys responsible for understanding DNS configurations.
> There are a lot of subtleties here -- offhand, delegations to the
> server, delegations from the server, and known-valid third-party DNS
> records that point to internal IPs or names.
> And quite aside from organizational issues, I personally work with
> both DNS products and firewall products. I would trust a DNS server
> to do complicated things with DNS a lot more than I would trust a
> firewall to do complicated things with DNS. The DNS servers
> (i.e. bind) have a lot more DNS-related knobs to turn, and clearly
> understand DNS better.
> In summary: yes, this can be worked around in a firewall, but it makes
> a lot of sense to provide a workaround in bind.
> - Morty
More information about the bind-users