Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 915316

Summary: ssh segfaults when trying to authenticate ldap user
Product: Red Hat Enterprise Linux 7 Reporter: Iveta Wiedermann <isenfeld>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact: Ondrej Moriš <omoris>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: dspurek, jsynacek, omoris
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pam-1.1.6-8.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-16 08:23:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reproducer none

Description Iveta Wiedermann 2013-02-25 13:39:01 UTC
Description of problem:
When ldap is enabled and set up with authconfig ldap user authentication through ssh leads to a crash of ssh.
getent and ldapsearch from client work just fine

Version-Release number of selected component (if applicable):
authconfig-6.2.5-1.el7.x86_64
nss-pam-ldapd-0.7.16-4.el7.x86_64
openldap-clients-2.4.33-3.el7.x86_64
openldap-servers-2.4.33-3.el7.x86_64
pam_ldap-185-14.el7.x86_64
openssh-6.1p1-4.el7.x86_64

How reproducible:
always

Steps to Reproduce:
On client:
1. authconfig --update --enableldap --enableldapauth --disablekrb5 --disablenis --ldapserver server_hostname --ldapbasedn 'dc=rhts,dc=redhat,dc=com' --enableforcelegacy
2. ssh ldaptester@localhost
3.

On server:
1. cat >/etc/openldap/slapd.conf <<-EOF
                include         /etc/openldap/schema/core.schema
                include         /etc/openldap/schema/cosine.schema
                include         /etc/openldap/schema/inetorgperson.schema
                include         /etc/openldap/schema/nis.schema
                allow bind_v2
                pidfile         /var/run/openldap/slapd.pid
                argsfile        /var/run/openldap/slapd.args
                database        bdb
                suffix          "dc=rhts,dc=redhat,dc=com"
                rootdn          "cn=Manager,dc=rhts,dc=redhat,dc=com"
                rootpw          {SSHA}somepw
                directory       /var/lib/ldap
                index objectClass                       eq,pres
                index ou,cn,mail,surname,givenname      eq,pres,sub
                index uidNumber,gidNumber,loginShell    eq,pres
                index uid,memberUid                     eq,pres,sub
                index nisMapName,nisMapEntry            eq,pres,sub
                EOF

2. rm -rf /etc/openldap/slapd.d/*
3. slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
4. chown ldap.ldap -R /etc/openldap/slapd.d /var/lib/ldap
5. start slapd service
6. ldapadd to add a user and group
  
Actual results:
From /var/log/messages on client

sshd[20600]: debug1: PAM: initializing for "ldaptester"
sshd[20600]: debug1: PAM: setting PAM_RHOST to "localhost"
sshd[20600]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[20600]: debug2: monitor_read: 50 used once, disabling now
sshd[20600]: debug1: userauth-request for user ldaptester service ssh-connection method password [preauth]
sshd[20600]: debug1: attempt 1 failures 0 [preauth]
sshd[20600]: debug2: input_userauth_request: try method password [preauth]
sshd[20600]: debug2: monitor_read: 3 used once, disabling now
sshd[20600]: debug2: monitor_read: 4 used once, disabling now
kernel: [ 8928.513761] sshd[20600]: segfault at 0 ip 00007fa21db6e894 sp 00007ffff6299608 error 4 in libc-2.16.so[7fa21dadb000+1ad000]
sshd[20600]: mm_log_handler: write: Broken pipe
systemd[1]: sshd.service: main process exited, code=killed, status=11/SEGV
systemd[1]: Unit sshd.service entered failed state


Expected results:
No ssh crash, authentication works

Additional info:

Comment 2 Jan Synacek 2013-02-27 07:18:48 UTC
Since it's sshd that's crashing, I'm switching the component to openssh.

Comment 3 David Spurek 2013-03-07 08:18:01 UTC
I have same problem when I add binddn and bindpw to /etc/nslcd.conf.
Then I see 
kernel: [ 5039.683884] sshd[8600]: segfault at 0 ip 00007f6a4a1ed894 sp 00007fffb0b87e68 error 4 in libc-2.16.so[7f6a4a15a000+1ad000]

in /var/log/messages.

I create singlehost reproducer in attachement.
First ssh login pass, second fail after add binddn and bindpw.

Comment 4 David Spurek 2013-03-07 08:18:47 UTC
Created attachment 706415 [details]
reproducer

Comment 5 Petr Lautrbach 2013-03-19 15:22:21 UTC
This seems to be issue of the pam library. There's no check of crypt()'s return value in bigcrypt.c:char *bigcrypt(const char *key, const char *salt):

107 #ifdef HAVE_CRYPT_R
108         tmp_ptr = crypt_r(plaintext_ptr, salt, cdata);  /* libc crypt_r() */
109 #else
110         tmp_ptr = crypt(plaintext_ptr, salt);   /* libc crypt() */
111 #endif
112         /* and place in the static area */
113         strncpy(cipher_ptr, tmp_ptr, 13);                    

backtrace:

#0  __strncpy_sse2 (s1=0x7f01a3401abf "", s2=0x0, n=13) at ./strncpy.c:41
        n4 = 3
        c = <optimized out>
        s = 0x7f01a3401ac0 ""
#1  0x00007f019cd05a45 in strncpy (__len=13, __src=<optimized out>, 
    __dest=0x7f01a3401ac0 "") at /usr/include/bits/string3.h:120
No locals.
#2  bigcrypt (key=key@entry=0x7f01a3401a50 "x", 
    salt=salt@entry=0x7f01a3401c60 "{SSHA}A41wdK4LTqBbyqqeWxHARusxQClMYwTy")
    at bigcrypt.c:113
        dec_c2_cryptbuf = 0x7f01a3401ac0 ""
        cdata = 0x7f01a2db6010
        keylen = <optimized out>
        n_seg = 1
        j = <optimized out>
        cipher_ptr = 0x7f01a3401ac0 ""
        plaintext_ptr = 0x7fff291c35d0 "x"
        tmp_ptr = <optimized out>
        salt_ptr = <optimized out>
        keybuf = "x", '\000' <repeats 129 times>
#3  0x00007f019cd093fb in verify_pwd_hash (p=p@entry=0x7f01a3401a50 "x", 
    hash=<optimized out>, nullok=nullok@entry=0) at passverify.c:97
        hash_len = <optimized out>
        pp = 0x0
        retval = <optimized out>
#4  0x00007f019cd089f1 in _unix_verify_password (pamh=pamh@entry=0x7f01a33f1a90, 
    name=0x7f01a33e5250 "ldapuser", p=0x7f01a3401a50 "x", ctrl=ctrl@entry=548)
    at support.c:660
        pwd = 0x7f01a3401f50
        salt = 0x7f01a3401c60 "{SSHA}A41wdK4LTqBbyqqeWxHARusxQClMYwTy"
        data_name = 0x7f01a3401e00 "-UN*X-FAIL-ldapuser"
        retval = 0
#5  0x00007f019cd06375 in pam_sm_authenticate (pamh=0x7f01a33f1a90, 
    flags=<optimized out>, argc=<optimized out>, argv=<optimized out>)
    at pam_unix_auth.c:180
        ctrl = 548
        retval = 0
        ret_data = 0x0
        name = 0x7f01a33e5250 "ldapuser"
        p = 0x7f01a3401a50
#6  0x00007f01a24e40e4 in _pam_dispatch_aux (use_cached_chain=<optimized out>, 
    resumed=<optimized out>, h=0x7f01a33f3d80, flags=1, pamh=0x7f01a33f1a90)
    at pam_dispatch.c:110
        retval = <optimized out>
        cached_retval = <optimized out>
        action = <optimized out>
        depth = <optimized out>
        status = <optimized out>
        prev_level = <optimized out>
        stack_level = 1
        impression = 0
        skip_depth = 0
        substates = <optimized out>
#7  _pam_dispatch (pamh=pamh@entry=0x7f01a33f1a90, flags=flags@entry=1, 
    choice=choice@entry=1) at pam_dispatch.c:407
        h = <optimized out>
        retval = <optimized out>
        use_cached_chain = <optimized out>
        resumed = <optimized out>
#8  0x00007f01a24e38b0 in pam_authenticate (pamh=0x7f01a33f1a90, flags=flags@entry=1)
    at pam_auth.c:34
        retval = <optimized out>
#9  0x00007f01a2f753b6 in sshpam_auth_passwd (authctxt=authctxt@entry=0x7f01a33e5920, 
    password=password@entry=0x7f01a3402920 "x") at auth-pam.c:1213
        flags = 1
        __func__ = "sshpam_auth_passwd"

Comment 6 Tomas Mraz 2013-03-19 16:26:38 UTC
Fixed in pam in F19 branch in Fedora.

Comment 7 Ondrej Moriš 2014-03-31 13:41:29 UTC
I have verified bug SanityOnly (ie. checking that proposed fix makes sense and that the patch is applied correctly). 

I just cannot reproduce this issue on the latest RHEL7 trees even with the old version of pam (1.1.6-3.el7). Both reproducers are passing with the latest version of pam. Returning a NULL value from crypt function in bigcrypt function represents an error according to the manual page of crypt. Unfortunately I cannot hit this error just by using wrong bind passwords there is probably something else which caused this error and that is not reproducible in the recent RHEL7.

Comment 8 Ludek Smid 2014-06-16 08:23:59 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.