bugzilla-daemon at mindrot.org
2003-Sep-01 14:02 UTC
[Bug 632] PAM conversation function does not return when connection is aborted
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.
bugzilla-daemon at mindrot.org
2003-Sep-01 20:16 UTC
[Bug 632] PAM conversation function does not return when connection is aborted
http://bugzilla.mindrot.org/show_bug.cgi?id=632 ------- Additional Comments From markus at openbsd.org 2003-09-02 06:16 ------- Markus, the PAM support has been completely replaced for the upcoming 3.7 release (the current code is from the author of OpenPAM). Could you please try with a recent snapshot from http://www.openssh.com/portable.html ? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-19 07:00 UTC
[Bug 632] PAM conversation function does not return when connection is aborted
http://bugzilla.mindrot.org/show_bug.cgi?id=632 ------- Additional Comments From djm at mindrot.org 2003-09-19 17:00 ------- We call pam_end indirectly via a fatal_cleanup in 3.7.x. Perhaps this should change. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.