Re: [Nagios-devel] Buggy debug output from nrpe since 2.1

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

Re: [Nagios-devel] Buggy debug output from nrpe since 2.1

Post by Guest »

--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

hey andreas,

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

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=20
> preferrable to xor-fold a timeval-struct into an int, like so:
>=20
> gettimeofday(&tv);
> sec =3D (int)(tv.tv_sec ^ tv.tv_sec >> (__WORDSIZE - 32));
> usec =3D (int)(tv.tv_usec ^ tv.tv_usec >> (__WORDSIZE - 32));
> seed =3D 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=20
> devices to drain it of entropy. The PRNG (in Linux at least) loops after=
=20
> 2^64 bytes unless the state is continuously and additively seeded (which=
=20
> it is).

i don't know enough about random devices, but had recieved complaints
=66rom 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


--liOOAslEiF7prFVr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/urxynjLPm522B0RAgvsAJ9qs/ThelVzX0A7Ig/56NQXI+++HACfaN5D
lUquPLtwVMp9869axZsRiOg=
=l3lI
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--





This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Locked