Possible security flaw in OpenSSH and/or pam_krb5

[Darren Tucker]

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.

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

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

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

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.

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

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

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

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