Re: [Nagios-devel] Buggy debug output from nrpe since 2.1
Posted: Fri Feb 24, 2006 3:16 am
--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]
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]