A few people have mentioned Stanford’s DNS rebinding paper over the last few weeks. I’ve known about it for several weeks when it magically appeared in my inbox. Absolutely nothing in it comes from me or any of the research I’ve done, so I should probably give my thoughts - late as they may be.

First the good - the paper does an excellent job of explaining why it’s a problem. It doesn’t mention some things that I probably would have, like clients that need to access localhost webservers (EG: Google Desktop) but alas, other than that minor omission I really liked how they showed that much of the web is ownable and how they did it with only $100. Not too shabby! If you want to test your browser go here (there’s no warning so if you want to protect yourself turn everything off before going there).

Now for the bad - a number of the mitigation techniques mentioned are pretty flawed. For instance, browser pinning by width (Page 7-8) only works if a webserver is moving within a class C. Every time I’ve done a webserver move, it has been well outside of the class C. The way they tested where DNS can rebind to is pretty flawed, because it doesn’t measure moves, it only measures where the hosts are in relation to one another. Trust me, for most companies in the process of datacenter moves (which I help with regularly), this is a silly mitigation technique.

Pinning based on Internet verses Intranet has some problems. I’ve been talking with the Microsoft folks about this, and I really think it makes less sense to think about it in terms of RFC1918 and more about zones. Sure RFC1918 and localhost represent a certain zone, but there’s lots of cases where IP based restrictions fall on the Internet, rather than behind NATted addresses. I’d rather leverage zones, and allow people (most likely sys-admins) to modify zones to include whatever is necessary. This same issue befalls the long term mitigation techniques mentioned at the firewall levels as well. Also, when people use proxies, all DNS resolving is done by the proxies. One more place that needs to be fixed.

The Hostname Authorization just seems like a huge can of worms. There’s really one of two ways to do this. The first would be to require a re-deployment of every webserver on earth, plus having an up to date registry of all bound hostnames - which if able to be queried could leak more information about the host than some administrators feel comfortable with. If you didn’t go that route and instead put this onus on DNS (as their paper suggests) it will require changes to all browsers to consume that data - which is pretty insanely complex and will take many years to get in everyone’s hands but do-able. But it also means that every webmaster on earth needs to modify their DNS records. Something tells me this long term solution is a bit of a pipe dream. This sorta reminds me of SPF. Who’s using that? Only the largest of large companies and banks, even though spam affects everyone.

So all in all, it was a pretty good paper, but I hope the browser companies seriously think through the mitigation techniques and the use cases before implementing them. There are some good thoughts there, so it’s not a waste of research, but I don’t think this paper will be the final word on where DNS rebinding is heading.

This entry was posted on Monday, August 13th, 2007 at 10:36 am and is filed under Webappsec. You can leave a response as well.