Possible security flaw in OpenSSH and/or pam_krb5

[Darren Tucker]

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.

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

(Examples: will it ask for the old password?  Will it ask for a 
confirmation of the new password?  Trusted-mode HP-UX will first ask you 
if you want to pick or generate a password, how does a blind 
conversation function answer that?  How does it even know what the PAM 
message means since the message types are opaque (other than string 
matching the text)?  And probably another gazillion platform-specific 
and module-specific variants I don't even know about.)

The passwd code is required to support password changing on platforms 
that don't have PAM, or are configured to not use PAM.  Using it for PAM 
in some case, while not ideal, is better than nothing and, as you point 
out, also works with SSHv1.

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

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

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