Re: glibc resolver weakness

[atatat () ATATDOT NET (Andrew Brown)]

> 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."