Possible security flaw in OpenSSH and/or pam_krb5

[Nicolas Williams]

On Fri, Jun 10, 2005 at 12:58:36PM +1000, Darren Tucker wrote:
> Nicolas Williams wrote:
> >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 :)
> 
> It does matter for the topic that started this entire thread: otherwise 
> the sshd process doing the PAM authentication could just call all of the 
> pam functions (authenticate, acct_mgmt, maybe chauthtok, session, 
> setcred) then exit.
> 
> The problem is one of the modules here is stashing some stuff using 
> pam_set_data and that's vanishing.  If PAM didn't require/desire that 
> the user's shell be a child of the process that called pam_authenticate 
> then this would not be an issue.

The data is vanishing because the calls aren't being made with the same
PAM handle (or it might be that the module has fork-safety issues and
the PAM calls aren't being made in the same process).

> >>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.
> 
> If you are referring to SSH2's USERAUTH_PASSWD_CHANGEREQ then that's a 
> completely separate can of worms.  Implementing that reliably via PAM 
> would likely be tricky because the conversation pam_chauthtok will have 
> doesn't map exactly to the single "new password" field that CHANGEREQ 
> will supply.  It's like the blind PasswordAuthentication case only worse.

Set PAM_OLDAUTHOK and PAM_AUTHTOK and call pam_chauthtok() with the
PAM_SILENT flag and a conversation function that returns an error.

If pam_chauthtok() fails, then userauth fails and you're done.

> [...]
> >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.
> 
> If you mean calling the event loop from within the conversation function 
> then OpenSSH used to do something like that (as far back as 2.5x which I 
> believe SunSSH was originally based on).  It predates my involvement 
> though, so I can't comment on what issues it had.  I suspect that 
> privsep makes it much tricker.  djm may wish to comment on this.

Privsep makes it tickier, but not that much trickier -- you just have to
nest the event loop in the monitor instead.

> >>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.
> 
> The handle is fine (it already exists in both processes I care about) 
> it's what the module(s) store during authentication via pam_set_data 
> that is the problem.  If the need for a separate process goes away then 
> this problem goes away too.

What separate process?  Why is sshd doing the PAM calls in different
processes, instead of in the same one?

Nico
--