Re: glibc resolver weakness

[smb () RESEARCH ATT COM (Steven M. Bellovin)]

In message <20000503034046.A9579 () nagash marmoc net>, antirez writes:
> Hi all,
>
> this is from glibc 2.1.3 resolver source code:
>
> u_int
> res_randomid()
> {
>        struct timeval now;
>
>        __gettimeofday(&now, NULL);
>        return (0xffff & (now.tv_sec ^ now.tv_usec ^ __getpid()));
> }
>
> A only-16-bit ID is weak "per-se", but this predictable algorithm
> is even worse. The glibc discards the replies with bad ID and wait
> for the reply with an ID that matchs, so if the target has ntpd or
> similar we are able to sync (using the rtt and so) and send spoofed
> queries with IDs in the range of our tv_usec guess (I assume that
> the pid and tv_sec are really a minor problem).
> Also if some query go in timeout the new id is computed as previuos_id++
> but seems better to get a new ID for every query. The fix may be
> a simple LCG, few entropy bits and some math like a^x (mod N)
> (see the OpenBSD ip->id fix).
> Anyway the problem is alive since 16 bits are just absurd, but seems
> that even in a fast structure like internet to change an old detail
> is a problem...
> I know about secure DNS protocols, but some additional RR like 'echo requet'
> and 'echo reply' can fix this without compatibility problem.
> I'm paranoic? I'll put on every query a 128-bit ID as 'echo response',
> so that I'll search it as 'echo reply' in the response.
> You aren't paranoic? Just use your resolvers without any changes.
> It's just an idea.

First, that code isn't specific to glibc; it's part of recent bind
distributions.  But I don't think one can do much better.

When this code was being written, Paul Vixie and I had a lot of discussions
about what to do.  The bottom line was that no matter what you did, 16 bits
was far too small to do it right, and that it therefore wasn't worth much
effort.  The only possible fixes involved changing the DNS protocol, and since
the right change -- dnssec -- was in progress, it didn't make sense to add
hacks.

Now, as it turned out dnssec was considerably further away than we thought it
would be.  Basically, though, what you see is an engineering judgement, that
given the other (very serious) vulnerabilities of the DNS, all that was called
for here was bringing it up to at least the same level of protection.  Heroic
measures here buy very little in terms of total security.  See
http://www.research.att.com/~smb/papers/dnshack.ps (or .pdf) for a discussion
of some of the more serious attacks.  Paul Vixie had a paper on his security
fixes to bind at the same Usenix Security conference (June 1995); I don't know
if it's available online.

                --Steve Bellovin