Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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) (deleted)
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.