Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 24 May 2001 00:14:04 +0400
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:

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.


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.