>> My understanding was that this particular CERT was due to a
>> predictable source port. So the TXID being random is good, but the
>> source port being non-random (or pseudo-random) is the problem.
>
> Right, but c-ares isn't setting the source port to anything AFAIK so it
> uses the random port provided by the OS. I believe the problems in some
> other implementations was because they explictily set the source port
> number.
No, this vulnerability as far as I can tell was the _combination_ of
a static query-source port and a non-random transaction id.
Historically BIND's default behavior was to use UDP port 53 for all
outgoing queries. I believe BIND9 changes this to a dynamic address
by _default_, but could be overwritten using 'query-source port 53'
in the configuration. The problem with the dynamic address BIND used,
as far as I can tell, is that it was only determined at startup and
never changed.
Since UDP is not a connection-based protocol, an attacker could send
'spoofed' responses to the server on the known port the server is
expecting to receive responses on. At that point, the only thing
a remote attacker would need to guess is the TXN ID... (Which if
it is predictable, is bad).
Obviously, one mitigation point that I need to verify c-ares performs
is validation that the response comes from the same network address
the question was sent to. I believe this should be done via
recvfrom() as the use of recv() doesn't provide the necessary info
to determine that... The source-port randomization, as Daniel said
is being handled by the OS for c-ares (not sure how 'random' it is,
it could potentially be an area for improvement if it is possible
to change). Actually, just opened ares_process.c, it appears to
use 'sread' which appears to be a #define to recv(), so there
may _actually_ be a potential issue here... I'm more familiar
with TCP than UDP though, so I need to research this further.
I found this 'best practices' draft, we might want to evaluate
how c-ares handles these different situations (at least the ones
which are applicable to client-only):
http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05
-Brad
Received on 2008-07-14