Possible security flaw in OpenSSH and/or pam_krb5

[Darren Tucker]

Let me preface this with some things I think we can agree on:

1) sshd's PAM interface isn't perfect.

2) PAM itself isn't perfect either.

I'd like to think sshd's PAM interface is improving.  We've certainly 
been working to that end.  There is still room for improvement, no 
question.  (If you look at the open sshd PAM bugs you will see that some 
of them have been raised by me.)

It's never going to be perfect.  Given the SSHv1 and v2 protocol specs 
and PAM as it stands I don't think it's possible.

Now some of my opinions on PAM from working with it in the context of 
sshd.  (I'm not going to justify them although I will if people wish):

3) PAM's blocking callback conversation interface makes using it from 
sshd harder than it has to be.  Similarly functional authentication 
systems with reentrant interfaces can be used with much less code (like 
an order of magnitude less).

4) Several other of its characteristics make PAM as a whole harder for 
sshd to use.

5) The differences between PAM implementations (and in some cases bugs 
in them) make it harder for sshd to work with all of them.

6) The multiple-messages part of the PAM conversation protocol (ie 
allowing more than one message per call to the conversation function) is 
more complex than necessary and this has been a source of bugs.

Frank Cusack wrote:
> On June 17, 2005 3:49:11 PM +1000 Damien Miller <djm at mindrot.org> wrote:
[...]
> But it does not follow the API correctly.  Isn't correctness a priority
> for the openssh folks?  It's not just the conversation function handling
> that's broken in openssh.

Would you please describe this (or provide a pointer to what you're 
referring to)?

> One of the large benefits of PAM is that organizations can write their
> own authentication functionality without having to rewrite every 
> application.

Sure, and that's a worthwhile goal.  Some of the ways it does it are 
problematic, though.

[...]

> Anyway, I withdraw my comment as I see (now that I examine recent
> sources) that PAM support is steadily improving. Documenting threads
> as an ugly hack is one of those nice improvements, IMHO. Why you
> added it in the first place is beyond my understanding.

It was in the FreeBSD code on which the current PAM code is based, and 
since then it's been the only general solution to modules that rely on 
pam_set_data/pam_get_data (in the main distribution, anyway).

Right now, it's a necessary (but unsupported) evil.  Once we have a 
better solution, it becomes an *un*necessary evil and it's history.

> As is why you
> refuse fairly trivial patches to correctly handle PAM conversations.

Again, would you please describe this or provide a pointer to the patch 
in question?

> Yet you have ugly code in there which supports much more obscure
> systems. (Although I hate to say that, because I myself always reject
> arguments for brokenness that are based on existing brokenness; just
> because something is already broken doesn't mean you make it more
> broken. But we're not talking about breaking openssh, we're talking 
> about improving it, from a system compatibility POV.)

Great, but let's talk about specific improvements rather than in 
generalities.

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