Possible security flaw in OpenSSH and/or pam_krb5

[Mike Dopheide]

Darren,

Thanks for taking the time to investigate this.  I've attached the 
requested debugging info, but I've also made a little bit of forward 
progress.

In the sshd PAM file you'll see the following line:
account     [default=bad success=ok user_unknown=ignore service_err=ignore 
system_err=ignore] /lib/security/$ISA/pam_krb5afs.so

By including this line I am asked to change my password.  As expected PAM 
first asks to change the Unix password and then for some reason it asks to 
change the Kerberos 5 password twice.  (As a side note, it ends up setting 
an /etc/shadow entry during one of these times it's changing my "Current 
Kerbero 5 Password".  That shouldn't have happened either and it confused 
me for about an hour.)

Without this line the debug output shows (attached sshd.debug):
debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success)

With this line, we see (attached sshd.debug2):
debug3: PAM: do_pam_account pam_acct_mgmt = 12 (Authentication token is no 
longer valid; new one required.)

In both of these cases pam_krb5 debug messages show:
Jun  8 22:42:54 quercus sshd[2510]: pam_krb5: get_int_tkt returned 
Password has expired

(Side note 2, I could never get pam_krb5 to write debug messages with it's 
'debug' option in the PAM config file.  I ended up hard coding the DEBUG 
#define.)

So I guess maybe all of this is just a misunderstanding of how to 
configure the PAM stack, but it seems broken to me that the default 
behavior for an expired principal is to succeed at authenticating.  

Confused,
Mike

PS.  You'll notice from the sshd_config and debug output that our sshd is 
patched to support native kerberos authentication with GSSAPI, but that 
shouldn't have any bearing on the PAM issues.

> > You can check what the PAM stack is returning by running sshd in debug 
> > mode and checking for the line "PAM: do_pam_account pam_acct_mgmt = x".
> 
> Further to this: I just did a quick test by overriding the return code 
> of pam_acct_mgmt() with PAM_NEW_AUTHTOK_REQD, which resulted in the 
> following behaviour or similar for at least v2+password, v2+pubkey and 
> v1+tis authentications.
> 
> $ ssh -p 2022 localhost
> Last login: Thu Jun  9 09:42:43 2005 from localhost
> debug3: channel 0: close_fds r -1 w -1 e -1 c -1
> WARNING: Your password has expired.
> You must change your password now and login again!
> Changing password for user dtucker.
> Changing password for dtucker
> (current) UNIX password:
> 
> (this is the output from "passwd", however for protocol 2 + 
> keyboard-interactive, or privsep=no for any combination of protocol and 
> authentication, the change will be done via pam_chauthtok().)
> 
> Could you please provide your sshd_config, PAM config and debug output 
> from sshd -ddd ?  Which non-kerberos authentication are you using?
> 
> 

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.tar.gz
Type: application/x-gzip
Size: 7875 bytes
Desc: 
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050608/6de6b789/attachment.bin