Bug 1073

Summary:

if userok rejects a user their creds still get set

Product:

Portable OpenSSH

Reporter:

paul moore <paul.moore>

Component:

Kerberos support

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED FIXED

Severity:

normal

CC:

simon

Priority:

Version:

3.9p1

Hardware:

All

OS:

All

Attachments:

Description	Flags
Delete delegated credentials if userok call fails	none
Fix arg to gss_release_cred	none

Description paul moore 2005-08-26 06:49:33 AEST

Tested on 3.9p1 - code inspection shows the same issue in 4.x
I have gss_auth setup on both ends. Works fine. I decide that I need to ssh to 
the server as a differnet user.
So I do ssh notme@<host>
Then 
a) I get prompted for a password for notme and log in ok
b) the credential cache is set to krb5cc_<uid>_xxxx and is loaded my 
originating credentials, even though I am not logged on as that principal

This is very surprising

The reason is that kuserok is called right at the end of auth, the creds have 
been forwarded and sshd is ready to set up the logged in users' envirnment; ten 
right at the last moment we decide not to allow gss to work - but sshd still 
stores the creds it has

one line fix to this. In ssh_gssapi_krb5_userok, after failure do
krb5_free_creds(krb_context, client->creds);
this blows the forwarded creds away and so storecreds (called later ) does 
nothing

Comment 1 Simon Wilkinson 2005-08-27 04:29:42 AEST

Created attachment 951 [details]
Delete delegated credentials if userok call fails

Comment 2 Simon Wilkinson 2005-08-27 04:30:50 AEST

Unfortunately, you can't (safely and portably) just call krb5_free_creds on the
client->creds structure, as its a pointer to a GSSAPI structure, which will not
necessarily be the same (or managed by the same allocator) as the underlying
Kerberos one.

I believe that the attached patch should solve the problem.

Comment 3 Damien Miller 2005-08-29 21:08:06 AEST

Comment on attachment 951 [details]
Delete delegated credentials if userok call fails

>+			gss_release_buffer(&lmin, &gssapi_client.displayname);
>+			gss_release_buffer(&lmin, &gssapi_client.exportedname);
>+			gss_release_cred(&lmin, gssapi_client.creds);

shouldn't that be &gssapi_client.creds?

Comment 4 Damien Miller 2005-08-29 21:18:59 AEST

Created attachment 952 [details]
Fix arg to gss_release_cred

Like this

Comment 5 Simon Wilkinson 2005-08-29 21:34:30 AEST

Comment on attachment 951 [details]
Delete delegated credentials if userok call fails

Indeed it should be - good catch. Obsoleting older patch.

Comment 6 Damien Miller 2005-08-31 08:07:42 AEST

Fix applied, will be in the imminent release (4.2)

Comment 7 Darren Tucker 2006-10-07 11:41:38 AEST

Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.