[14848] in bugtraq
Re: glibc resolver weakness
daemon@ATHENA.MIT.EDU (Gary Ellison)
Tue May 9 13:51:49 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14614.65259.207737.199063@bootsy.eng.sun.com>
Date: Mon, 8 May 2000 10:52:43 -0700
Reply-To: gfe@interhack.net
From: Gary Ellison <gfe@INTERHACK.NET>
X-To: smb@RESEARCH.ATT.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000503220959.0C18935DC2@smb.research.att.com>
>>>>> " " == Steven M Bellovin <smb@RESEARCH.ATT.COM> writes:
> 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.
Both papers are available on the USENIX website
http://www.usenix.org/publications/library/proceedings/security95/bellovin.html
http://www.usenix.org/publications/library/proceedings/security95/vixie.html
--
mailto:gfe@interhack.net http://www.interhack.net/people/gfe/
"Be liberal in what you accept, and conservative in what you send."
-- RFC1123 --
