openssh bugs - May 2006 - [Bug 1189] Stacked PAM modules hang root logout

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

           Summary: Stacked PAM modules hang root logout
           Product: Portable OpenSSH
           Version: 4.3p2
          Platform: UltraSparc
        OS/Version: Solaris
            Status: NEW
          Severity: normal
          Priority: P2
         Component: PAM support
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: wknox at mitre.org


When connecting to a server as root with a key-pair if stacked PAM
modules are being used, the connection hangs upon disconnect. This only
affects the root user and only when connection is made with the
key-pair. I have (or will have) attached the /etc/pam.conf in question,
the debug output from both the client and the server with the hang
point indicated, the build output and a stack backtrace. The server in
question is a fairly recently patched Solaris 8 (117350-28), and I
would be happy to answer any questions about anything else. The PAM
module in question, by the way, is from RSA to provide SecurID access.




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

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





------- Comment #1 from wknox at mitre.org  2006-05-16 06:44 -------
Created an attachment (id=1133)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1133&action=view)
Build options




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

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





------- Comment #2 from wknox at mitre.org  2006-05-16 06:45 -------
Created an attachment (id=1134)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1134&action=view)
Stack backtrace




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

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





------- Comment #3 from wknox at mitre.org  2006-05-16 06:48 -------
Created an attachment (id=1135)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1135&action=view)
/etc/pam.conf file




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

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





------- Comment #4 from wknox at mitre.org  2006-05-16 06:49 -------
Created an attachment (id=1136)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1136&action=view)
Debug output from server




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

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





------- Comment #5 from wknox at mitre.org  2006-05-16 06:49 -------
Created an attachment (id=1137)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1137&action=view)
Debug output from client




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

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





------- Comment #6 from wknox at mitre.org  2006-05-20 03:06 -------
Additional testing reveals that

1) the hang is caused by having the PAM module in question alone
performing authentication - it doesn't have to be stacked
2) non-root users will also hang using pubkey auth if sshd is
configured without PrivSep
3) not all PAM modules exhibit this behavior

I suppose this bug boils down to one of, if pubkey auth succeeded, why
would the auth PAM modules be getting touched at all? Even if I have a
clunky PAM module, I would have thought it wouldn't matter if it is not
being called for auth.

I am about to attach the output of truss -vpoll -f -d on the sshd
command in question. The hang occurs between the timestamps 15.69 and
26.18 (which is where I hit Ctrl-C).

Thanks in advance for any help or pointers to a clue, if I am
overlooking something (aside from getting rid of the PAM module in
question).




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

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





------- Comment #7 from wknox at mitre.org  2006-05-20 03:08 -------
Created an attachment (id=1138)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1138&action=view)
Truss output from sshd (truss -vpoll -f -d)




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

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


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #8 from dtucker at zip.com.au  2006-05-20 07:42 -------
(In reply to comment #6)
> Additional testing reveals that
> 
> 1) the hang is caused by having the PAM module in question alone
> performing authentication - it doesn't have to be stacked
> 2) non-root users will also hang using pubkey auth if sshd is
> configured without PrivSep
> 3) not all PAM modules exhibit this behavior
> 
> I suppose this bug boils down to one of, if pubkey auth succeeded, why
> would the auth PAM modules be getting touched at all? Even if I have a
> clunky PAM module, I would have thought it wouldn't matter if it is not
> being called for auth.
pam_setcred() uses the auth stack too and that's called regardless of
the ssh authentication method.
> I am about to attach the output of truss -vpoll -f -d on the sshd
> command in question. The hang occurs between the timestamps 15.69 and
> 26.18 (which is where I hit Ctrl-C).
> 
> Thanks in advance for any help or pointers to a clue, if I am
> overlooking something (aside from getting rid of the PAM module in
> question).
Try lsof'ing (or equivalent) the hanging sshd (and/or its shell
subprocess if it still has one).  I suspect that your recalcitrant
module is leaking file descriptors and sshd is waiting for the leaked
desriptor to close.

Excellent bug report, btw :-)




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

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





------- Comment #9 from wknox at mitre.org  2006-05-22 12:54 -------
I'm attaching the lsof and pfiles output of the child sshd process (the
shell process is still there, but labelled a defunct process with no
open files) - I am not familiar enough with the mechanics of sshd at
this point to spot a leaked FD awaiting closure, but ain't nothing
leaping out to me. I'll also open a case with RSA about their module to
see if they can shed any light.

Thanks for the help.




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

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





------- Comment #10 from wknox at mitre.org  2006-05-22 12:55 -------
Created an attachment (id=1140)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1140&action=view)
lsof of child sshd process




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

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





------- Comment #11 from wknox at mitre.org  2006-05-22 12:56 -------
Created an attachment (id=1141)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1141&action=view)
pfiles of child sshd process




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