[dns-operations] Use of Views/ACLs to defeat DNS rebinding/pinning attacks?
simonw at zynet.net
Tue Aug 7 18:17:58 UTC 2007
On Tuesday 07 August 2007 17:49, Roland Dobbins wrote:
> I understand all this, and fail to see its relevance, either. DDoS
> is a very general problem, yet the use of BGP as the control-plane
> signaling mechanism for S/RTBH isn't pooh-poohed because DDoS isn't a
> 'BGP problem'.
The problem is you can't constrain DNS because of a problem in application X,
because there are many applications that use the DNS, and the subset of all
these constraints means that no workable DNS model might be left that
satisfies all of them simultaneously.
The DNS behaviour was like this when the web was born, so the security model
for web browsers should have taken this into account. It isn't a new problem.
It is also an obvious subversion of the security model, so I assume the
blackhats have been doing it for years, it certainly occurred to me to ask
this question as soon as I had the Java security model explained to me.
I note the Flash security model (version 8 anyway) does specifically say it
relies on the DNS security (and mentions spoofing), but it doesn't discuss
the case where the DNS server may be run by someone with malicious intent.
Given the evolution of the web so far, probably the only realistic security
ActiveX (or disable ActiveX completely) etc, along side security in depth.
If you think that a switch between remote and local IP addresses should be
detected and handled, it is probably best to deploy this into browsers (or
plugins), since these applications have the best chance of identifying when
such a change is malicious. It also avoid committing to DNS as the name
providing system (which given the history of Microsoft's name resolution, is
probably not something you want to hard code).
Most browsers already subvert the DNS to minimize these problems by caching
DNS records longer than they are valid, which people using DNS as a fail-over
mechanism sometimes get surprised by.
But it seems relatively clear that it is the responsibility of the security
manager of the application in question to identify a change of IP address (or
unusual IP addresses in a DNS response), and behave sensibly. Clearly if some
check on IP addresses by the security managers were in place, the current
ugly caching behaviour could be removed, and people could switch to using DNS
to do funky things with load balancing for the web and the like.
i.e. If you make a DNS request, and get a well formed answer, it is the
requestors responsibility to make sense of the response.
I see no problem with the ISC or someone producing client code and/or an API,
or other tools, suitable for such a security manager - since the problem is
applications, but I don't think the checks belong in the core protocol or
name servers themselves.
Now one might argue that we need a protocol that allows us to distinguish
security domains correctly, but the current state of the DNS with its
vulnerability to spoofing is clearly not the protocol to base that on. Wasn't
there a paper, by a Rachel(?), saying precisely this mentioned here a few
The general solution here is difficult, the Flash approach (assuming you can
get a reliable name system), is that the target host advertises who it
i.e. You retrieve;
It then changes to;
You could imagine the security manager retrieving information from 10.0.0.1
that says that "18.104.22.168" is a friend (or not). Of course you want an
efficient protocols so that merely asking 10.0.0.1 who is a friend isn't a
DDoS. One could imagine using the DNS (reverse lookup style) to store this
information (assuming we get around to securing the DNS in time).
Also one could use HTTPS, for Flash at least in theory. This means you can
reasonably run flash served over HTTPS (as I understand it) without being
vulnerable (although I haven't tested this), as this then defines a security
domain as all those with a valid secret certificate for this domain, since
the hosts being attacked don't have that secret certificate, they would only
be vulnerable to DDoS or other "trivial" attacks.
Afraid it boils down to people made compromises in building the web, don't
start from here ;)
More information about the dns-operations