[14808] in bugtraq
Re: glibc resolver weakness
daemon@ATHENA.MIT.EDU (Andrew Brown)
Sat May 6 16:35:10 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000503170801.A12576@noc.untraceable.net>
Date: Wed, 3 May 2000 17:08:02 -0400
Reply-To: Andrew Brown <atatat@atatdot.net>
From: Andrew Brown <atatat@ATATDOT.NET>
X-To: antirez <antirez@linuxcare.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000503034046.A9579@nagash.marmoc.net>; from
antirez@linuxcare.com on Wed, May 03, 2000 at 03:40:46AM +0200
>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).
the resolver is generally not exploitable, although theoretical
exploits have been posted for snoop, which has a buffer overrun in
its dns routines.
recursive name servers, on the other hand, can be exploited due to
this weakness. modern versions of bind (8.2-rel and above) have
support for a random id query pool that guards against this
vulnerability.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
andrew@crossbar.com * "information is power -- share the wealth."
