On Wed, 3 Jun 2015, Petr Spacek wrote:
It is somewhat questionable whether DNS rebinding vulnerabilities are,
in fact, a problem which should be solved at the client side. But
Oh yes. DNS pinning in browser is just a band-aid and not proper solution. I
would argue that DNS rebinding attack is caused by generic lack of ingress
filtering on multiple levels.
I'm not sure we are talking about the same thing here? A DNS rebinding
attack works by tricking the browser to resolve something, on which it
makes a security decision, eg nohats.ca is 193.110.157.102. The TTL for
that would be 0. The browser checks this is a valid src/dst pair. Then
it allows this transaction. Another piece of the browser is allowed to
run, usually something like flash with its own DNS code, and it has to
redo the query since the original TTL was 0. Now the remote DNS server
answers with an another IP address that happens to be in your browser's
local network. And now the flash plugin is scanning the local network
against the actual browser's security policy.
Forcing a minimal TTL prevents this, but I think browsers have gone
overboard on ignoring "bad DNS TTLs" for the sake of speed.
Note that if you are running unbound as the DNS server, you can
configure it to not allow RFC1918 space for all but white listed
domains, but this is hard to administrate, and prone to failure when
using split DNS. Although ISP caches could surely enable the feature
that no RFC1918 may ever appear in public DNS answers.
We learned to filter IP packets on firewalls to make sure that packets with
internal source addresses come really from interfaces connected to internal
networks and the very same principle should apply everywhere...
It's hard to do without knowing what kind of network you are on. Can it
be trusted or not? If you are at a coffeeshop and starbucks.com resolves
to 192.168.1.1, is that trusted or malicious? If you are on a wifi
network, should your laptop allow DNS answers for www.redhat.com to be
192.168.1.1 ? It's a hard problem if you try to solve it without
whitelists and blacklists, which are in itself not a very good solution.
This problem is similar to the network join problem itself. Is this wifi
network trusted? Since coffeeshops use WPA with passwords scribbled on
the whiteboard, we have no other way than asking the user.
Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
