Possible security flaw in OpenSSH and/or pam_krb5

[Darren Tucker]

Darren Tucker wrote:
> I can't comment on the Kerberos aspects, but as far as sshd's PAM 
> interface goes:
> 
> Mike Dopheide wrote:
> [...]
> 
>>  - If the application is not calling, or ignoring non-success return
>>    values of pam_acct_mgmt() yet still allowing access to the account,
>>    then the application has a gaping hole and is at fault.
> 
> sshd calls pam_acct_mgmt (via auth{1,2}.c -> auth-pam.c:do_pam_account). 
>  If it returns PAM_NEW_AUTHTOK_REQD, sshd forces a password change, 
> either via keyboard-interactive or once the session starts.
> 
> 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?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.