Possible security flaw in OpenSSH and/or pam_krb5

[Nicolas Williams]

On Fri, Jun 10, 2005 at 10:10:05AM +1000, Darren Tucker wrote:
> Nicolas Williams wrote:
> [...]
> >Pretty much all PAM calls for a given login attempt and session have to
> >be executed with the same PAM handle, in the same process, and with all
> >privileges.  That's just how PAM works.
> 
> You forgot: and that process (or one of its decendants) must later 
> become the user's shell.

That's true, but I didn't forget it -- it wasn't relevant here yet :)

> >I figure this answers my question in my other reply -- sshd must be
> >calling pam_chauthtok() in the context of a pty channel, in a child
> >process or something like that, rather than in the context of
> >keyboard-interactive userauth.
> 
> It depends.  For the current release:
> 
> For SSHv2 and keyboard-interactive it's done via kbdint, privsep or no.
> 
> For SSHv1 and SSHv2 passwordauthentication when privsep=yes, it uses 
> passwd, because by the time the pty session is opened, sshd no longer 
> has the privilege to call pam_chauthtok().   For privsep=no it uses 
> pam_chauthtok(), because it can.

Basically, I would either support CHANGEREQ as best I could, or not
allow userauth to complete if the password can't be changed that way or
if the protocol is SSHv1.

> [...]
> >I agree that this is an obnoxious feature of PAM.  I'm thinking about
> >how we could make it better, but for the time being, that's how it is.
> 
> If you're looking for ways to improve PAM then I've got a long list, but 
> the biggest single improvement you could make is to come up with a 
> rentrant replacement for the blocking callback conversation function model.

I have a long list too.  As OpenSolaris comes online we'll have lots of
opportunity to go over these lists, design and implement improvements.

As for the conversation function issue you have, I've advised the
OpenSSH team before on how to handle the matter, namely: nest the
dispatch_run() event loop.  That is how Solaris 10's sshd does it, no
fork(), no threads.  There was one tricky issue: unwinding the stack on
keyboard-interactive userauth abandonment, but it was not that tricky.

> A distant second would be some way to export and import the 
> module-private data, or to provide shared-mmap'ped space to store it. 
> (eg zlib provides a callback registration for allocating memory which 
> sshd uses.)

Hadn't thought of that.  If the issue is that you want to move PAM
handles across processes I'd like to understand just why.

> If PAM had either of those things then we would not be having this 
> discussion.  The blocking callback is the crux of the matter, though: it 
> either causes the other problems or makes them harder to deal with.

Sun had to deal with the same problem and found a simple solution.  See
above.

> >However, this does not excuse sshd, or any other application, not
> >handling PAM properly (see above).   When pam_acct_mgmt() returns
> >PAM_NEW_AUTHTOK_REQD while processing userauths other than
> >keyboard-interactive sshd should force failure of the current userauth
> >and then indicate that only keyboard-interactive userauth may continue.
> >When the client tries keyboard-interactive start PAM processing from
> >scratch, call pam_authenticate(), pam_acct_mgmt() and, if it
> >returns PAM_NEW_AUTHTOK_REQD, call pam_chauthtok(), then pam_setcred(),
> >then pam_open_session(),
> 
> The setcred/session order depends on whose documentation you believe, 
> and it's the other way around according to yours (pam_setcred(3PAM)).

Indeed, my error.

> >only then can SSH userauth be considered
> >complete.
> 
> PAM's architecture makes this difficult for sshd.  Any of those 
> functions may block and attempt to interact with the user during which 
> time sshd's event loop isn't running, and the event loop the only means 
> sshd has to communicate with the user.  Snookered.

See above!

> And before you say "threads": your PAM modules may be thread-safe (and I 
> don't know if they are or not) but I'll guarantee that not every module 
> is (and the LinuxPAM docs effectively give module writers a license to 
> write thread-unsafe code).

See above!

Look ma, no threads!

Nico
--