[6740] in Kerberos
Re: Kerberos Weakness (COAST Findings)
daemon@ATHENA.MIT.EDU (Thor Lancelot Simon)
Fri Feb 23 03:13:56 1996
To: kerberos@MIT.EDU
Date: 23 Feb 1996 02:13:27 -0500
From: tls@panix.com (Thor Lancelot Simon)
Reply-To: tls@rek.tjls.com
In article <nsx3f8318yl.fsf@dcl.mit.edu>,
Theodore Y. Ts'o <tytso@dcl.mit.edu> 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.
The Kerberos that's part of NetBSD is eBones-derived.
It doesn't suffer from the problem in question, as one would tend to expect --
With des_random_key available and no access to the MIT code, why use the
old, broken (as it turned out) ranom_key function?
I'm not even sure random_key is included in eBones. Was it stripped out when
Bones was produced?
On the other hand, eBones has plenty of other problems, mostly resulting from
confusion about the type of C_BLOCK and an implementation choice that masks
rampant confusion about whether lots of libkrb functions take *C_BLOCK or
C_BLOCK. I think I nailed all of these in NetBSD; I know I didn't catch some
mistaken prototypes, though.
--
Thor Lancelot Simon tls@rek.tjls.com
love is an angel disguised as lust
