glibc resolver weakness

[Andreas Jaeger <aj at suse dot de>]

I've been pointed to the appended bugtraq article (see
http://www.securityfocus.com/).

The code we use is the same as in the latest bind8 release - and bind9
seems to use a completly new way.

What should we do about this?

Andreas

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 To:
           BugTraq
 Subject:
           glibc resolver weakness
 Date:
           Tue May 02 2000 21:40:46
 Author:
           antirez
 Message-ID:
           <20000503034046.A9579@nagash.marmoc.net>


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.

regards,
antirez

--
Salvatore Sanfilippo, Open Source Developer, Linuxcare Italia spa
+39.049.8024648 tel, +39.049.8036484 fax
antirez@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de