OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: glibc resolver weakness
From: Andrew Brown (atatatATATDOT.NET)
Date: Wed May 03 2000 - 16:08:02 CDT

>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" >-----|
codewarriordaemon.org             * "ah!  i see you have the internet
twofsonetgraffiti.com (Andrew Brown)                that goes *ping*!"
andrewcrossbar.com       * "information is power -- share the wealth."