[conspire] DNS vulnerability details
rick at linuxmafia.com
Fri Jul 25 16:44:32 PDT 2008
Quoting Ruben Safir (ruben at mrbrklyn.com):
> With due respect, I fail to see how random outgoing ports will provide
> more security,
Because the man-in-the-middle attacker, posing as the queried
recursive-resolver nameserver, has to send a forged response back not
_merely_ with the correct QID (transaction ID), but also delivered on the
correct port. If the delivery port for responses, the one used to
originate the query, is always 53/UDP, then it's much easier to forge
a credible fake response -- 2^16 QID value possibilites, rather than
those permutations _plus_ 2^16 possible ports. ~32 bits of variability
is better than 16, when you're trying to reject forged data.
> The server is still listening on a single know port and send responses
> from a random port (one that is hopefully not being used for vnc) but
> to connect to a known client port.
The _queried_ server is not the problem. The problem resides with the
recursive-resolver nameserver that's doing the asking: It's far too
easy for an imposter to send it credibly faked responses -- that, in
turn, can be used to poison the querying nameserver machine's cache.
That is why the problematic scenario is a recursive-resolver nameserver
that sends _its_ recursive-resolver requests always on UDP port 53, that
_also_ caches received data. (It also explains why processes that send
out recursive queries but don't cache the results -- libc's "stub"
resolver and most "firewall" appliances' nameservers being obvious
examples -- aren't a problem: You can send them poisoned information,
but that information won't persist.)
More information about the conspire