Bug 632

Summary:

PAM conversation function does not return when connection is aborted

Product:

Portable OpenSSH

Reporter:

Markus Kuhn <Markus.Kuhn>

Component:

PAM support

Assignee:

OpenSSH Bugzilla mailing list <openssh-bugs>

Status:

CLOSED FIXED

Severity:

major

Keywords:

patch

Priority:

Version:

3.6.1p2

Hardware:

All

OS:

Linux

URL:

http://www.cl.cam.ac.uk/~mgk25/otpw.html#opensshbug

Attachments:

Description	Flags
Don't fatal on msg functions	none

Description Markus Kuhn 2003-09-02 00:02:22 AEST

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.

Comment 1 Markus Friedl 2003-09-02 06:16:23 AEST

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
?

Comment 2 Damien Miller 2003-09-19 17:00:39 AEST

We call pam_end indirectly via a fatal_cleanup in 3.7.x. Perhaps this should change.

Comment 3 Doug 2003-11-13 04:08:47 AEDT

Considering this is a security bug (it does not scrub memory as it should and 
for other pam modules expose other vulnerabilities) as well as a functionality 
bug which seems to involve calling one function instead of another, I would 
think hope and encourge that getting it fixed be a priority.

Comment 4 Damien Miller 2003-11-16 16:08:20 AEDT

Please don't make changes to other people's bugs, unless you are going to help.

Comment 5 Damien Miller 2003-11-16 16:32:29 AEDT

Created attachment 501 [details]
Don't fatal on msg functions

The removes the remaining indirect ways that pam_end could be called from the
kbd-int conversation function in -current portable.

I'd suggest the msg.[ch] changes for inclusion in the OpenBSD version too.

Comment 6 Markus Friedl 2003-11-17 01:41:04 AEDT

   

the msg.c changes make sense to me...

Comment 7 Damien Miller 2003-12-16 23:21:21 AEDT

The changes were committed a month ago.

Comment 8 Damien Miller 2004-04-14 12:24:19 AEST

Mass change of RESOLVED bugs to CLOSED