Bugtraq mailing list archives
glibc resolver weakness
From: antirez () LINUXCARE COM (antirez)
Date: Wed, 3 May 2000 03:40:46 +0200
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.
Current thread:
- Re: Possible issue with Cisco on-line help?, (continued)
- Re: Possible issue with Cisco on-line help? Lisa Napier (May 09)
- 4ward:It's a blue world! deepquest () NETSCAPE NET (May 02)
- Denial of service attack against tcpdump bretonh () PARANOIA PGCI CA (May 02)
- Re: Denial of service attack against tcpdump antirez (May 03)
- Re: Denial of service attack against tcpdump Sebastian (May 03)
- Re: Denial of service attack against tcpdump Dragos Ruiu (May 03)
- Re: Denial of service attack against tcpdump Gerald Combs (May 03)
- "ILOVEYOU" virus analysis Steve Wolfe (May 04)
- 2.2.14 Kernel exec/open bug (?) The Cr0W (May 05)
- Re: Denial of service attack against tcpdump Hugo.van.der.Kooij () CAIW NL (May 09)
- glibc resolver weakness antirez (May 02)
- Re: glibc resolver weakness Bennett Todd (May 03)
- Re: glibc resolver weakness Valdis.Kletnieks () VT EDU (May 03)
- Re: glibc resolver weakness Andrew Brown (May 03)
- Cayman 3220-H DSL Router DOS cassius () HUSHMAIL COM (May 05)
- Fun with UltraBoard V1.6X rudi carell (May 03)
- Fwd: tcpdump workaround against dnsloop exploit. THE INFAMOUS (May 03)
- Re: tcpdump workaround against dnsloop exploit. David Schwartz (May 06)
- NetBSD Security Advisory 2000-002 Daniel Carosone (May 06)
- [NHC20000504a.0: NetBSD Panics when sent unaligned IP options] NHC Research (May 06)
- Re: Fwd: tcpdump workaround against dnsloop exploit. Sebastian (May 07)
- Fwd: tcpdump workaround against dnsloop exploit. THE INFAMOUS (May 03)
(Thread continues...)