[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20010524001404.A620@openwall.com>
Date: Thu, 24 May 2001 00:14:04 +0400
From: solar@...nwall.com
To: owl-users@...ts.openwall.com
Subject: Re: glibc resolver dns query ids
On Wed, May 23, 2001 at 06:58:07PM +0300, Jarno Huuskonen wrote:
> I noticed that you have added a patch for glibc-2.1.3 to use more random
> dns query ids (the same patch you have for bind-4.9.x ?).
Yes. I've adjusted the code such that it is now shared for both the
glibc patch and BIND 4.9.x-OW.
> Have you done any tests to see if the patch adds any performance
> penalties etc. ? (My rough guess would be that any penalties will be very
> minimal).
You're right, there's no noticeable performance impact. Even when
used in BIND (which, unlike a client resolver library, serves multiple
client machines), the performance is still very good:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
named 103 0.2 22.5 29220 28784 ? S May 12 34:57 /named/named -t /named -u named
This is BIND 4.9.8-OW1, serving about 950 primary zones (including
reverse for a /19) and used as the primary caching nameserver for
client machines in the /19. It produces about 1 GB of DNS traffic
monthly (that leaves our network). The machine is a Pentium II at
350 MHz, and the named takes 0.2% CPU.
> (Also have you tested bind-8.2.3 with 'use-id-pool yes;' to see if it
> uses decent query id's and how it compares to your res_randomid patch ?)
No. I wonder what they're using for the randomness source (I haven't
checked the code, I'm not using it).
> Have you done (or considered) a similar patch for glibc __gen_tempname ?
> Here's part of the __gen_tempname code (looks similar to the res_randomid):
> value += ((uint64_t) tv.tv_usec << 16) ^ tv.tv_sec ^ __getpid ();
Yes. This is on my TODO for our glibc package. There's actually a
worse problem with this code where it doesn't actually add _any_
randomness between the attempts to create a file. But this is at
worst a DoS against a particular libc call.
> (I guess it couldn't hurt if __gen_tempname would accept more than six X's).
Well, OpenBSD programs typically pass 10 X's which aren't fully used
on glibc. So, yes, this could be improved as well, but I don't think
makes that much a difference.
> This probably isn't very interesting but might help some (closed source)
> programs (if you have to use them) that use mktemp/tempnam with or
> without O_EXCL.
Actually, I'm more concerned with the DoS possibility against programs
which correctly use mkstemp(3). This possibility does exist with the
current glibc.
> Have you considered using something like prngd as a random source ?
I don't think there's any need for prngd. If anything is found to be
wrong with our in-kernel randomness pool, that would need to be fixed.
> OpenSSH seems to recommend prngd.
Only for systems which lack /dev/*random.
--
/sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
