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@mindrot.org
ReportedBy: Markus.Kuhn@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.
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@mindrot.org
ReportedBy: Markus.Kuhn@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.