Bug 101799 - OpenSSH server crashes when Kerberos 5 authentication is enabled and a non-root user login is attempted
Summary: OpenSSH server crashes when Kerberos 5 authentication is enabled and a non-ro...
Keywords:
Status: CLOSED DUPLICATE of bug 101183
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh
Version: 9
Hardware: i586
OS: Linux
high
high
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-06 23:22 UTC by Economou, Matthew
Modified: 2006-02-21 18:58 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-02-21 18:58:00 UTC
Embargoed:


Attachments (Terms of Use)
GDB output for sshd (Red Hat Linux 9, openssh-server-3.5p1-6.9) (9.23 KB, text/plain)
2003-08-06 23:23 UTC, Economou, Matthew
no flags Details

Description Economou, Matthew 2003-08-06 23:22:16 UTC
Description of problem:

When Kerberos 5 authentication is configured (i.e. via authconfig),
sshd's connection-specific child process segfaults (SIGSEGV) when a
non-root user attempts to log onto the system.  It doesn't matter of
the non-root user authenticates locally or via Kerberos 5.  The parent
sshd instance is unaffected and continues to field connection attempts
on port 22.

I observed similar behavior on Red Hat Linux 8 after updating
openssh-server from 3.4p1-2 to 3.4p1-4.

From the perspective of the client, the connection is dropped before
the user is prompted for a password.

The problem can be duplicated by running sshd in debug mode (the "-d"
option to sshd) under GDB.  A GDB transcript that includes a backtrace
is attached to this bug report.

Version-Release number of selected component (if applicable):

openssh-server-3.5p1-6.9

How reproducible:

Every time

Steps to Reproduce:

1. Run authconfig and enable Kerberos 5 authentication.
2. A reboot is NOT required.
3. Restarting sshd is NOT required.
4. Use the ssh client to attempt to log into a non-root account,
   e.g. ssh user@localhost.
5. It does not matter if the account authenticates via Kerberos 5 or
   locally via /etc/shadow.
6. To return to normal operations, re-run authconfig and disable
   Kerberos 5 authentication.

Actual results:

After the connection encryption is negotiated, the ssh client will
lose contact with the sshd server child instance and report
"Connection closed by <NAME OR ADDRESS>", e.g. "Connection closed by
127.0.0.1".

When running sshd in debug mode under GDB, one will observe a segfault
(signal SIGSEV) in malloc_consolidate() from /lib/libc.so.6.

Expected results:

The user should have been authenticated as customary for ssh, via the
pam_krb5 or pam_unix modules.  Obviously, the segfault in
malloc_consolidate() should not occur.

Additional info:

The relevant error as reported when running sshd under GDB in debug
mode (sshd's debug messages are prefixed with "debug3"):

debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
Program received signal SIGSEGV, Segmentation fault.
0x40239e38 in malloc_consolidate () from /lib/libc.so.6

A backtrace at this point shows the following:

#0  0x40239e38 in malloc_consolidate () from /lib/libc.so.6
#1  0x402395a5 in _int_malloc () from /lib/libc.so.6
#2  0x40238830 in malloc () from /lib/libc.so.6
#3  0x401ac6d2 in krb5_sendto_kdc () from /usr/kerberos/lib/libkrb5.so.3
#4  0x40195213 in krb5_get_renewed_creds () from /usr/kerberos/lib/libkrb5.so.3
#5  0x40196440 in krb5_get_init_creds () from /usr/kerberos/lib/libkrb5.so.3
#6  0x40197894 in krb5_get_init_creds_password () 
from /usr/kerberos/lib/libkrb5.so.3
#7  0x404f5a8f in pam_sm_authenticate () 
from /lib/security/../../lib/security/pam_krb5.so
#8  0x40027c09 in pam_fail_delay () from /lib/libpam.so.0
#9  0x40027d93 in _pam_dispatch () from /lib/libpam.so.0
#10 0x400169b2 in pam_sm_chauthtok () from /lib/security/pam_stack.so
#11 0x40015d1e in pam_sm_authenticate () from /lib/security/pam_stack.so
#12 0x40027c09 in pam_fail_delay () from /lib/libpam.so.0
#13 0x40027d93 in _pam_dispatch () from /lib/libpam.so.0
#14 0x40029868 in pam_authenticate () from /lib/libpam.so.0
#15 0x0805439a in chroot ()
#16 0x0805469d in chroot ()
#17 0x08055119 in chroot ()
#18 0x0805f531 in chroot ()
#19 0x0805ed00 in chroot ()
#20 0x0805e9a5 in chroot ()
#21 0x0804d055 in chroot ()
#22 0x0804e1b4 in chroot ()
#23 0x401e15cd in __libc_start_main () from /lib/libc.so.6

Comment 1 Economou, Matthew 2003-08-06 23:23:16 UTC
Created attachment 93464 [details]
GDB output for sshd (Red Hat Linux 9, openssh-server-3.5p1-6.9)

Comment 2 Ken Weaverling 2003-08-11 18:48:28 UTC
There are other open bugs about this as well...

bug 101361
bug 101183

This one affects my workplace, so I'm keeping close tabs on it.  :)


Comment 3 Mark J. Cox 2003-09-25 09:53:12 UTC

*** This bug has been marked as a duplicate of 101183 ***

Comment 4 Andre ten Bohmer 2003-09-25 14:15:36 UTC
On a Red Hat 7.3 server this is still an issue, tested with openssh-server-
3.1p1-14, the session is disconnected immediately after entering the user name. 
When using the root account, there is a time-out before the password dialog 
appears (behavior by design I believe).
Tested on (two different servers) Red Hat 9.0 openssh-3.5p1-11, after entering 
the user account the password prompt never shows up (time out follows after a 
while). Root account behavior same as on the Red Hat 7.3 server.

Comment 5 Red Hat Bugzilla 2006-02-21 18:58:00 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


Note You need to log in before you can comment on or make changes to this bug.