5060372 2000-05-03 20:42 /56 rader/ Postmaster
Mottagare: Bugtraq (import) <10721>
Ärende: glibc resolver weakness
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.12i
Message-ID: <20000503034046.A9579@nagash.marmoc.net>
Date: Wed, 3 May 2000 03:40:46 +0200
Reply-To: antirez@linuxcare.com
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.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.
(5060372) ------------------------------------------(Ombruten)
5068370 2000-05-06 20:36 /69 rader/ Postmaster
Mottagare: Bugtraq (import) <10748>
Ärende: Re: glibc resolver weakness
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20000503220959.0C18935DC2@smb.research.att.com>
Date: Wed, 3 May 2000 18:09:58 -0400
Reply-To: smb@RESEARCH.ATT.COM
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "Steven M. Bellovin" <smb@RESEARCH.ATT.COM>
X-To: antirez@linuxcare.com
X-cc: BUGTRAQ@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
In message <20000503034046.A9579@nagash.marmoc.net>, antirez writes:
>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.
First, that code isn't specific to glibc; it's part of recent bind
distributions. But I don't think one can do much better.
When this code was being written, Paul Vixie and I had a lot of
discussions about what to do. The bottom line was that no matter
what you did, 16 bits was far too small to do it right, and that it
therefore wasn't worth much effort. The only possible fixes involved
changing the DNS protocol, and since the right change -- dnssec --
was in progress, it didn't make sense to add hacks.
Now, as it turned out dnssec was considerably further away than we
thought it would be. Basically, though, what you see is an
engineering judgement, that given the other (very serious)
vulnerabilities of the DNS, all that was called for here was bringing
it up to at least the same level of protection. Heroic measures here
buy very little in terms of total security. See
http://www.research.att.com/~smb/papers/dnshack.ps (or .pdf) for a
discussion of some of the more serious attacks. Paul Vixie had a
paper on his security fixes to bind at the same Usenix Security
conference (June 1995); I don't know if it's available online.
--Steve Bellovin
(5068370) ------------------------------------------(Ombruten)
5068628 2000-05-06 21:37 /51 rader/ Postmaster
Mottagare: Bugtraq (import) <10753>
Ärende: Re: glibc resolver weakness
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :)
Message-ID: <20000503170801.A12576@noc.untraceable.net>
Date: Wed, 3 May 2000 17:08:02 -0400
Reply-To: Andrew Brown <atatat@atatdot.net>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Andrew Brown <atatat@atatdot.net>
X-To: antirez <antirez@linuxcare.com>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000503034046.A9579@nagash.marmoc.net>; fro
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."
(5068628) ------------------------------------------