Buggy debug output from nrpe since 2.1
sean finney
seanius at seanius.net
Fri Feb 24 08:03:15 CET 2006
hi guys,
On Thu, Feb 23, 2006 at 09:21:16PM +0100, Gerhard Lausser wrote:
> Ethan, you applied my nrpe-2.3-allow_weak_random_seed patch to the 2.4
> branch. Would you be so kind and add another line, which came to my mind
> later? The results of the rand() calls in the last fallback might be
> predictable, so seeding with the current time is necessary.
> It's just a "srand(time(NULL));" after the syslog call. I attached a patch
> file for the 1.42
i'd like to advise against this, and maybe comment on a bit
more on the use of random bits in nrpe.
srand should really only be called once, and with a value that is as
unpredictable as possible. instead of calling srand(time(NULL)), i
might suggest something like the following:
seed=(int)time(NULL)*311-getpid()*359+getppid()*383;
which makes remote attacks on the prng more or less impossible, and local
ones difficult at best. i'm not sure why you would need to call it
multiple times.
also, nrpe currently reads a random byte from /dev/urandom for seeding
it the first time. i'd like to point out that this means that the prng
is seeded with a value that is strictly between 0 and 255 inclusive.
that's not a very large search space for someone trying to crack
something.
it also drains precious entropy from the system by reading from the
random device. for both of these reasons this code has been
patched out of the code in debian and replaced with something like
the above example. i would suggest that you do something similar.
if you really want to keep a "random byte" in the seed, i suppose
it would be best to include it in the above example, perhaps
replacing one of the prime numbers. however, i'm not convinced
that it gets you much.
sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20060224/b2785b41/attachment.sig>
More information about the Developers
mailing list