Possible security flaw in OpenSSH and/or pam_krb5

[Darren Tucker]

Mike Dopheide wrote:
> Darren,
> 
> Thanks for taking the time to investigate this.

You're welcome.

> 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

I can guess why the line wasn't there: I'll bet that logins via ssh 
pubkey authentications won't work any more.

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

Regarding the double password request: I see you're using 
keyboard-interactive.  I suspect it's another manifestation of bug #688: 
the process where you authenticate exits, taking pam_krb5's private 
stash of data with it.  When sshd later calls pam_chauthtok() pam_krb5 
has to reestablish it.

Unfortunately there's no good, general solution for this right now. 
Patch #642 from bug #688 will help in the kerberos case as will building 
sshd with -DUNSUPPORTED_POSIX_THREADS_HACK (aka -DUSE_POSIX_THREADS for 
versions < 4.1p1).

You can also try "ssh -o PreferredAuthentications=password yourserver", 
but be aware that this will behave differently with and without privsep.

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

That's just how PAM works: you don't get to know about things like 
password expiry until later.  A module could potentially force a change 
during pam_authenticate via the conversation mechanism before allowing 
the authentication to succeed, however that would break things 
(including sshd's PasswordAuthentication via PAM).

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

Probably not but you really ought to reproduce problems with unpatched 
versions before reporting them.

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