[6771] in Kerberos
Re: Kerberos Weakness (COAST Findings)
daemon@ATHENA.MIT.EDU (Thor Lancelot Simon)
Tue Feb 27 04:09:32 1996
To: kerberos@MIT.EDU
Date: 27 Feb 1996 03:20:41 -0500
From: tls@panix.com (Thor Lancelot Simon)
Reply-To: tls@rek.tjls.com
In article <4gsbnh$i0o@newnews.iafrica.com>,
Mark Murray <markm@iafrica.com> wrote:
>tytso@dcl.mit.edu (Theodore Y. Ts'o) wrote:
>
>>In article <Dn2qsH.Du9.0.staffin.dcs.ed.ac.uk@dcs.ed.ac.uk> gdmr@dcs.ed.ac.uk (George Ross) writes:
>>>Do the various "bones" versions have the problem? If so, are fixes available
>>>and how do we get them?
>
>>The bug was in the portion of the Kerberos sources which would have been
>>stripped out by the "Bones" distribution made at MIT. I haven't
>>personally had a chance to take a look at the "eBones" distribution,
>>which had the encryption calls added back outside of the US of A,
>>to see if it also has similar problems.
>
>eBones _does_ have the problem. The guy who did the conversion also
>used the old RNG (the new wasn't even in MIT DES). FreeBSD has
>corrected eBones in a way that I would imagine is very similar to
>MIT. Look on a FreeBSD site close to you.
Looking at the eBones-based Kerberos which is in NetBSD, I note three relevant
facts:
A) des_random_key does not appear to be used anywhere, ever. In fact, it
doesn't even appear to be in our libdes, though the manual page for it still
exists.
B) The liner notes for Eric Young's libdes list "des_random_key fixed; it
wasn't random" as of sometime in 1990.
C) des_init_random_number_generator uses the process ID, the host name, the
current time to the nearest second, and "a secret key, possibly shared by a
number of servers". That doesn't sound like it has a whole hell of a lot of
new entropy, but the secret key is supposed to be, well, _secret_, right? Is
this a description of the problem, or the solution?
--
Thor Lancelot Simon tls@rek.tjls.com
love is an angel disguised as lust
