Possible security flaw in OpenSSH and/or pam_krb5

[Nicolas Williams]

On Thu Jun  9 09:58:11 2005, Darren Tucker wrote:
> 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:

While I can see how you can make this behaviour not be insecure, it is
clearly not ideal: it works only if the user was trying to open a pty
channel, otherwise the client's requests fail or, if the client wanted
only to do local port forwarding, then the client might wait a long time
to find out that something went wrong with user authentication.

The SSHv2 protocol provides for a much cleaner way to do this: force use
of keyboard-interactive userauth and let PAM drive keyboard-interactive
to change the user's expired 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().)

But will the call to pam_chauthtok() happen in the context of
keyboard-interactive userauth?  Or does it still require a pty channel?

Nico
--