[Bug 632] PAM conversation function does not return when connection is aborted

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=632

           Summary: PAM conversation function does not return when
                    connection is aborted
           Product: Portable OpenSSH
           Version: 3.6.1p2
          Platform: All
               URL: http://www.cl.cam.ac.uk/~mgk25/otpw.html#opensshbug
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: PAM support
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: Markus.Kuhn at cl.cam.ac.uk


When a user presses Ctrl-C in ssh while being prompted by the PAM conversation
function during a keyboard-interactive authentication, then sshd's conversation
function does not return to the PAM library with PAM_CONV_ERR. Instead sshd
calls pam_end() directly from inside the conversation function.

This is in violation of "The Linux-PAM application developers' guide" (draft
0.73, 2000-12-02), which states in section 3.2.1, page 14 that "should an error
occur the application should [...] simply return PAM_CONV_ERR".

Why is calling pam_end() directly from within the conversation function causing
a problem?

Linux-PAM keeps as a debugging aid in its handler variable pamh->caller_is track
of whether the calling thread was supposed to come from the application
(caller_is=2) or from the PAM module (caller_is=1). (See
Linux-PAM-0.75/libpam/pam_private.h for the relevant macros.) The incorrect call
of pam_end() from within the conversation function results in an error message
by Linux-PAM, because Linux-PAM thinks, based on its pamh->caller_is=1 value,
that pam_end() was accidentally called by the module. As a result, pam_end()
aborts and none of the PAM data structures are cleaned up properly. In
particular, and call-back functions that a PAM module might have registered ro
release resources are not called.

As a result, PAM modules that create, for example, a lock file before entering
the conversation function are not given a chance to release their resources,
leading to malfunctions. Another security-critical side effect of this bug is
that the memory scrubbing that PAM normally applies carefully to any password
buffers never takes place if the ssh connection is aborted. As a result,
passwords are more likely to leak out into swap space or core dumps.

I discussed this issue with Linux-PAM author Andrew Morgan, and he agreed that
this is clearly a bug in the PAM support of OpenSSH.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.