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.