Buggy debug output from nrpe since 2.1

[sean finney]

hey andreas,

On Fri, Feb 24, 2006 at 11:38:46AM +0100, Andreas Ericsson wrote:
> >       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.
> >
> 
> Unfortunately it doesn't. It's possible to determine what a hosts system 
> clock is set to by either watching ntp traffic to/from the host (with 
> great accuracy), or by watching arbitrary packets sent from the host 

but the remote attacker would not know the pid/ppid, correct?
or did you mean that it doesn't for the local attacker?  it's still
within the realm of feasibility, though i'd posit it's still a
modest improvement over a 1-byte seed value.

> True. It would be far better to read a full int. For time-seeding it's 
> preferrable to xor-fold a timeval-struct into an int, like so:
> 
> gettimeofday(&tv);
> sec = (int)(tv.tv_sec ^ tv.tv_sec >> (__WORDSIZE - 32));
> usec = (int)(tv.tv_usec ^ tv.tv_usec >> (__WORDSIZE - 32));
> seed = sec ^ usec;

agreed--that's a nice trick i hadn't heard of.  would it be worth
putting in some local information as well (getpid()?), or is the
granularity of the usec field enough that a remote attacker couldn't
estimate the value?  anyway i'm putting that down in in my notes for
future reference :)

> You would have to read an exceedingly large data-set from the random 
> devices to drain it of entropy. The PRNG (in Linux at least) loops after 
> 2^64 bytes unless the state is continuously and additively seeded (which 
> it is).

i don't know enough about random devices, but had recieved complaints
from a couple folks about the issue of "useless entropy draining".  not
knowing more, and seeing a problem i did understand (1-byte seeding)
i went ahead and applied the patch.


	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/299119dc/attachment.sig>