[dns-operations] Use of Views/ACLs to defeat DNS rebinding/pinning attacks?

[Simon Waters]

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 
model is whitelisting trusted sites (by domain) for Javascript, Flash, Java, 
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 
common between Java, Flash, Javascript, and a number other Internet 
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 
weeks ago?

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 
trusts.

i.e. You retrieve;

badguy.example.com 1.2.3.4

It then changes to;

badguy.example.com 10.0.0.1

You could imagine the security manager retrieving information from 10.0.0.1 
that says that "1.2.3.4" 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 ;)

 Simon