Possible security flaw in OpenSSH and/or pam_krb5

[Darren Tucker]

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".

>  - A PAM module may defer authentication and authorization, in
>    password-change-required situations, to pam_sm_chauthtok(3PAM), but
>    if so it must: a) return PAM_SUCCESS from its
>    pam_sm_authenticate(3PAM) _AND_ b) return PAM_NEW_AUTHTOK_REQD from
>    its pam_sm_acct_mgmt(3PAM).
[...]
> If anyone has any questions regarding our setup I'll do my best to
> answer them.  We're hoping someone can duplicate the problem and we're
> willing to test any fixes/patches that come up.

What do the PAM config files look like?  Can you provide sshd debug output?

-- 
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.