[14768] in bugtraq
glibc resolver weakness
daemon@ATHENA.MIT.EDU (antirez)
Wed May 3 18:01:54 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-Id: <20000503034046.A9579@nagash.marmoc.net>
Date: Wed, 3 May 2000 03:40:46 +0200
Reply-To: antirez@linuxcare.com
From: antirez <antirez@LINUXCARE.COM>
X-To: bugtraq@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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.
