[1766] in Kerberos_V5_Development
protocol flaw (160 lines) (was: krbdev vs krbcore)
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Fri Sep 20 14:40:11 1996
To: tytso@MIT.EDU
Cc: don@MIT.EDU, krbcore@MIT.EDU
Date: Fri, 20 Sep 1996 14:39:31 -0400
From: "Donald T. Davis" <don@cam.ov.com>
ted, and the rest of the mit krb team:
i hadn't known about the krbcore list (afaik, it didn't
exist when i worked on krb5 in '90 & '91). i'm glad to
hear that it exists, because it's just the right place
for me to discreetly remind you all of a krb-protocol
flaw i told ted and sam about in the spring.
THE PROTOCOL BUG
it often happens that a hurried or distracted user will
mistype his username and password a few times in a row.
when this happens, it's easy for the user to get out of
synch with the prompts, so that he types his _password_
into the _username_ prompt:
login: don.root<cr>
password: e^x,du.dx<cr>
login: don.root<cr>
password: e^x,du,dx<cr>
... <-- user gets out of synch
login: e^x,du/dx<cr> <-- right pw, wrong place
password: don.root<cr>
...
everyone i've asked says that they've caught themselves
doing this on occasion, and i've certainly done it myself.
now, when a user gets out of synch like this, his password
(or a mistyped version of it) goes _in_the_clear_ from the
client to the kdc, in his request for a tgt. normally, the
kdc will deny the request, saying to the client, "no such
principal" (or some such error packet). eventually, the
user gets back in synch and gets his tgt.
now, the trouble is that this series of failed requests
is eminently valuable to an eavesdropper, not least
because administrative users are very often hurried and
distracted when they login. the bad guy watches the net
for "no such principal" replies, and looks at all of the
contemporary tgt-requests from that same client address.
if the username that got the "no such username" reply
is very different from a successful request's username,
then the anomalous "username" is probably very _close_
to the user's password. indeed, if the user stays out
of synch for two rounds, the attacker will have a very
easy search:
... (user gets out of synch)
login: e^x,du,dx<cr>
password: don.root<cr>
login: e^x.du/dx<cr>
password: don.root<cr>
... (user gets back in synch)
login: don.root<cr>
password: e^x,du/dx<cr>
here, the attacker sees only e^x,du,dx and e^x.du/dx ,
but he can surmise that both are likely to be nearly
correct. so, he can reasonably expect one of four
possibilities to be correct, and he'd be right:
e^x.du,dx
e^x.du/dx
e^x,du,dx
e^x,du/dx <-- correct pw
clearly, this is not a problem with the kinit command
itself, because that command never prompts alternately
for username and password. the problem arises only when
the user can alternately type his name & pw repeatedly,
as some login and telnet clients allow.
REPAIR
it's impossible to prevent the user completely from
typing his password into a username prompt, but it is
possible to make this mishap less common, and to make
these cleartext-password tgt-requests less obvious to
an eavesdropper. first, to make the mishap less common,
a failed password-entry should raise a "retry? (yn)"
prompt, just so as to force _two_ carriage-returns
before the username:
login: don.root<cr>
password: e^x,du.dx<cr>
retry?(yn): <cr>
login: don.root<cr>
password: e^x,du/dx<cr>
this extra prompt and carriage-return make it very
hard for the user to get out of synch, because his
cycle of login keystrokes becomes
NAME<cr>PW<cr><cr>NAME<cr>PW<cr><cr>NAME... .
even if i'm not looking at the screen very closely,
the double carriage-returns help me not to get out
of synch with the prompts. further, with this extra
retry prompt, even if i were somehow to lose track
and were thereby to type my pw into the login prompt,
i would have to have typed my username into the retry
prompt beforehand:
...
retry?(yn): don.root<cr>
login: e^x,du/dx<cr>
password: <cr>
however, it's plain that this sequence is impossible;
the retry prompt would react to the nonsensical reply
by refusing to raise another login prompt. instead,
the retry code would either raise another retry prompt,
or would abort the client altogether.
another repair, suggested by ted, would be good at
the packet level. when the kdc gets a request for a
nonexistent username, it should _not_ send an error
packet to the client. instead, the kdc should reply
with a normal-looking krb_as_reply message, made of
random bits. then the client will attempt to decrypt
the random bits with some key (probably the real
username), the decryption will fail, and the user
will then see a retry prompt.
note that neither fix is effective by itself, because
the retry prompt merely reduces the frequency of this
kind of password exposure, while the random reply just
makes the exposure a little harder for the eavesdropper
to detect. with both fixes in place, the eavesdropper
could still look for a rapid series of tgt-requests from
the same source-address, in hope that a bad typist has
gotten out of synch. but, detecting a usage-pattern is
a little harder for the attacker, than simply looking
for error-packets.
EXPOSURE
finally, i'd like to emphasize that this is a fairly
grievous protocol flaw, and that even if you fix it
soon in v5, a lot of v4 users will remain vulnerable
to this attack. accordingly, i hope that you won't log
this bug in the bug database, and that you won't reveal
the bug in the source-tree's rcs logs. i'm even nervous
about comments in the code that makes the fix. if we
knew a bad guy had already found this hole, i wouldn't
recommend this "security by obscurity" approach.
as it is though, by preserving the obscurity in krbv5,
we can protect the security of v4's large installed base.
alternatively, maybe the right thing to do is to make
an extraordinary update to mit's v4 source-tree, notify
cert, and urge all v4 sites to pick up the fix. i feel
queasy about weakening the v4 sites even briefly, though.
i understand that this problem couldn't be a priority
for beta 7, but i hope at least ted's proposed fix will
get into the sources someday soon. note that i'm sending
this to krbcore instead of krbdev, because i don't want
to publicise this bug. however, since i don't belong to
krbcore (and should not belong), i hope you all will copy
me explicitly, in any discussion of the bug that follows
this reminder.
-don davis, boston
