[2213] in Kerberos-V5-bugs
Re: security hole in v4 and v5 login?
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Tue Sep 10 11:23:00 1996
Date: Tue, 10 Sep 1996 11:22:40 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: schemers@stanford.edu, krb5-bugs@MIT.EDU
In-Reply-To: [2211]
schemers> some changes to our locally hacked up login program, and
schemers> stumbled across a possible race condition that exists in
schemers> the v4 and v5 login programs.
I tend to agree with you that the particular section of code
you quote could use some re-writing, but I disagree that there is a
race condition if the sticky bit is set on /tmp.
Ted and I discussed this yesterday, realized that the problem does not
exist if the sticky bit is set on /tmp, but decided that we should fix
it because it could be *perceived* as a Unix security hole in
Kerberos. The solution we decided on is:
do normal as-root login stuff
read creds from root-owned ccache into memory
destroy ccache
setuid(user)
re-create ccache as user, write credds into it
do normal as-user login stuff
This way, the ccache that is left for the user was created by the
user, so no chown is necessary. This fixes the security threat, and
it also fixes another bug: using chown assumes the ccache is a file,
and it might not be (it might be shared memory, for example). It
accomplishes both of these goals without requiring real/effective uid
swapping, which apparently is difficult to get right on all platforms.
I should have this change done by today, and Ted and I agreed that it
should be in beta 7 (again, to eliminate the possible perception of a
security hole). I'll be sending the patches to some other krb5
developers for auditing before committing them.
Barry
