Bug 434735 - SASL ANONYMOUS is broken in x86_64
SASL ANONYMOUS is broken in x86_64
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - SASL (Show other bugs)
1.1.0
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
:
Depends On:
Blocks: 434914 389_1.2.6
  Show dependency treegraph
 
Reported: 2008-02-24 22:48 EST by Frank Delahoyde
Modified: 2015-12-07 12:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 12:07:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch (3.47 KB, patch)
2010-02-17 13:57 EST, Nathan Kinder
nhosoi: review+
Details | Diff

  None (edit)
Description Frank Delahoyde 2008-02-24 22:48:06 EST
Description of problem:
SASL support is broken in x86_64 build of 1.1.0 B2007.355.1657.
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
From system log:
Feb 24 19:22:29 sts-gw-2 ns-slapd: unable to dlopen
/usr/lib/sasl2/libsasldb.so.2: /usr/lib/sasl2/libsasldb.so.2: wrong ELF class:
ELFCLASS32
Feb 24 19:22:29 sts-gw-2 ns-slapd: unable to dlopen
/usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF
class: ELFCLASS32
Feb 24 19:22:29 sts-gw-2 ns-slapd: unable to dlopen
/usr/lib/sasl2/liblogin.so.2: /usr/lib/sasl2/liblogin.so.2: wrong ELF class:
ELFCLASS32
Feb 24 19:22:29 sts-gw-2 ns-slapd: unable to dlopen
/usr/lib/sasl2/libplain.so.2: /usr/lib/sasl2/libplain.so.2: wrong ELF class:
ELFCLASS32
Comment 1 Rich Megginson 2008-02-25 14:16:01 EST
The x86_64 server should not be attempting to load /usr/lib/sasl2 - it should be
using /usr/lib64/sasl2.  Can you confirm that you have installed the
fedora-ds-base.x86_64 package?
Comment 2 Frank Delahoyde 2008-02-25 15:42:14 EST
Yes, it's the x86_64 package (fedora-ds-base-1.1.0-3.fc6) on CentOS-5.1.

# file /usr/sbin/ns-slapd
/usr/sbin/ns-slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped

# ldd /usr/sbin/ns-slapd
        libslapd.so.0 => /usr/lib64/dirsrv/libslapd.so.0 (0x00002aaaaaaad000)
        libssldap60.so => /usr/lib64/libssldap60.so (0x00002aaaaad9c000)
        libprldap60.so => /usr/lib64/libprldap60.so (0x0000003b9d000000)
        libldap60.so => /usr/lib64/libldap60.so (0x0000003b9d400000)
        libldif60.so => /usr/lib64/libldif60.so (0x0000003b9d800000)
        libssl3.so => /usr/lib64/libssl3.so (0x000000364bc00000)
        libnss3.so => /usr/lib64/libnss3.so (0x000000364b800000)
        libsoftokn3.so => /usr/lib64/libsoftokn3.so (0x00002aaaaafaa000)
        libplc4.so => /usr/lib64/libplc4.so (0x000000364a400000)
        libplds4.so => /usr/lib64/libplds4.so (0x000000364a800000)
        libnspr4.so => /usr/lib64/libnspr4.so (0x000000364a000000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003b9cc00000)
        libsvrcore.so.0 => /usr/lib64/libsvrcore.so.0 (0x0000003b9e000000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003637a00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003638600000)
        libsmime3.so => /usr/lib64/libsmime3.so (0x000000364b000000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003638200000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x000000363fc00000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003648800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003636a00000)
Comment 3 Rich Megginson 2008-02-25 15:51:42 EST
rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl

On my RHEL5 x86_64 system I have these:
cyrus-sasl-gssapi.i386
cyrus-sasl-lib.i386
cyrus-sasl.x86_64
cyrus-sasl-plain.x86_64
cyrus-sasl.i386
cyrus-sasl-md5.x86_64
cyrus-sasl-plain.i386
cyrus-sasl-ntlm.i386
cyrus-sasl-devel.x86_64
cyrus-sasl-lib.x86_64
cyrus-sasl-md5.i386
Comment 4 Frank Delahoyde 2008-02-25 16:37:26 EST
I have these on my system:

rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl
cyrus-sasl-lib.x86_64
cyrus-sasl-plain.i386
cyrus-sasl-plain.x86_64
cyrus-sasl-md5.x86_64
cyrus-sasl-lib.i386
cyrus-sasl.i386
cyrus-sasl-devel.x86_64
cyrus-sasl.x86_64
cyrus-sasl-gssapi.x86_64
Comment 5 Rich Megginson 2008-02-25 16:56:07 EST
env | grep -i sasl
grep -i sasl_path /etc/rc.d/init.d/dirsrv /etc/sysconfig/dirsrv
/etc/dirsrv/slapd-*/dse.ldif
Comment 6 Frank Delahoyde 2008-02-25 17:40:54 EST
No, nothing. So then I:
gdb program `pgrep ns-slapd`
...
> Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2
> Reading symbols from /usr/lib64/sasl2/libdigestmd5.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so.2
> Reading symbols from /lib64/libcrypto.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libcrypto.so.6
> Reading symbols from /usr/lib64/libz.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/libz.so.1
> Reading symbols from /usr/lib64/sasl2/libcrammd5.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/sasl2/libcrammd5.so.2
> Reading symbols from /usr/lib64/sasl2/libgssapiv2.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/libgssapiv2.so.2
> Reading symbols from /usr/lib64/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
> Reading symbols from /usr/lib64/libkrb5.so.3...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/libkrb5.so.3
> Reading symbols from /usr/lib64/libk5crypto.so.3...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/libk5crypto.so.3
> Reading symbols from /lib64/libcom_err.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /lib64/libcom_err.so.2
> Reading symbols from /usr/lib64/libkrb5support.so.0...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/libkrb5support.so.0
> Reading symbols from /lib64/libkeyutils.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /lib64/libkeyutils.so.1
> Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libselinux.so.1
> Reading symbols from /lib64/libsepol.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /lib64/libsepol.so.1
> Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...(no debugging
symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2
> Reading symbols from /usr/lib64/sasl2/liblogin.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/liblogin.so.2
> Reading symbols from /usr/lib64/sasl2/libplain.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/sasl2/libplain.so.2

It seems to be finding the /usr/lib64/sasl2 shared libraries.

What prompted this bug report was that I have a working fds 1.0.4
installation that has autofs authenticating via a proxy user. autofs
can only authenticate using SASL mechanisms. With fds 1.1 the server
always returns LDAP_INVALID_CREDENTIALS (49):

[24/Feb/2008:14:11:24 -0800] conn=352 fd=69 slot=69 connection from
132.239.23.78 to 132.239.92.137
[24/Feb/2008:14:11:24 -0800] conn=352 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
name="startTLS"
[24/Feb/2008:14:11:24 -0800] conn=352 op=0 RESULT err=0 tag=120 nentries=0 etime=0
[24/Feb/2008:14:11:24 -0800] conn=352 SSL 256-bit AES
[24/Feb/2008:14:11:24 -0800] conn=352 op=1 BIND dn="" method=sasl version=3
mech=ANONYMOUS
[24/Feb/2008:14:11:24 -0800] conn=352 op=1 RESULT err=49 tag=97 nentries=0 etime=0
[24/Feb/2008:14:11:24 -0800] conn=352 op=2 UNBIND

Comment 7 Rich Megginson 2008-02-25 21:59:59 EST
Are you using mech=ANONYMOUS with 1.0.4?
Comment 8 Frank Delahoyde 2008-02-25 22:44:15 EST
Yes I am. I didn't find an alternative SASL mechanism compatible with
both autofs and fds. I'm not particularly happy about the security implications.
Comment 9 Rich Megginson 2008-02-25 22:54:42 EST
So the bug is that SASL ANONYMOUS works with Fedora DS 1.0.4 but is broken with
Fedora DS 1.1?
Comment 10 Frank Delahoyde 2008-02-25 23:11:12 EST
That is apparently tha case. Sorry for the red-herrings.
Comment 11 Rich Megginson 2008-02-26 12:48:42 EST
The SASL code didn't really change much with 1.1.  The SASL mapping code did - I
wonder if that has something to do with this problem?  Are you really attempting
to bind as anonymous (dn="") or is that just what the log reports?  Have you
tried another mechanism such as LOGIN or PLAIN?  Does autofs really require
SASL?  Is there no way to use LDAP simple bind?
Comment 12 Frank Delahoyde 2008-02-26 19:23:38 EST
We had a SASL mapping set up for a proxy user. autofs was supplying the sasl
authcid matching that mapping. Today we got autofs working with ssl certificates,
so as far as I'm concerned this bug report can be closed. Thanks for your
help and prompt responses. -frank
Comment 13 Rich Megginson 2008-02-26 19:35:17 EST
Thanks.  I'm going to leave it open - you probably won't be the last person to
run into this.  Thanks for all of the info, btw.
Comment 14 omight 2008-08-12 11:05:53 EDT
I also have the following messages on my 64 bit Red Hat directory server:
# grep lib /var/log/messages
Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/liblogin.so.2: /usr/lib/sasl2/liblogin.so.2: wrong ELF class: ELFCLASS32
Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF class: ELFCLASS32
Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/libplain.so.2: /usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32

My problem is that SSL does not seem to work when setting up a LDAP synchronization to an active directory machine. Without SSL it works ok.
If anyone has pointers how to resolve this, that would be very welcome.

More info:
Installed base: Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)

# file /usr/sbin/ns-slapd
/usr/sbin/ns-slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

# ldd /usr/sbin/ns-slapd
        libslapd.so.0 => /usr/lib64/dirsrv/libslapd.so.0 (0x00002af86dc7d000)
        libssldap60.so => /usr/lib64/libssldap60.so (0x00002af86df65000)
        libprldap60.so => /usr/lib64/libprldap60.so (0x0000003f48400000)
        libldap60.so => /usr/lib64/libldap60.so (0x0000003f47800000)
        libldif60.so => /usr/lib64/libldif60.so (0x0000003f48000000)
        libssl3.so => /usr/lib64/libssl3.so (0x00002af86e172000)
        libnss3.so => /usr/lib64/libnss3.so (0x00002af86e3a5000)
        libsoftokn3.so => /usr/lib64/libsoftokn3.so (0x00002af86e6e8000)
        libplc4.so => /usr/lib64/libplc4.so (0x00002af86e942000)
        libplds4.so => /usr/lib64/libplds4.so (0x00002af86eb46000)
        libnspr4.so => /usr/lib64/libnspr4.so (0x00002af86ed4a000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003f3b600000)
        libsvrcore.so.0 => /usr/lib64/libsvrcore.so.0 (0x0000003f46c00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003f28400000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f29000000)
        libsmime3.so => /usr/lib64/libsmime3.so (0x00002af86ef85000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003f28c00000)
        libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002af86f1b0000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003f31a00000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003f3ae00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003f28000000)

# rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl
cyrus-sasl-lib.x86_64
cyrus-sasl-gssapi.x86_64
cyrus-sasl-lib.i386
cyrus-sasl-plain.x86_64
cyrus-sasl.x86_64
cyrus-sasl-md5.x86_64
cyrus-sasl-plain.i386

# env | grep -i sasl
# grep -i sasl_path /etc/rc.d/init.d/dirsrv /etc/sysconfig/dirsrv /etc/dirsrv/slapd-*/dse.ldif
#
Comment 15 Rich Megginson 2008-08-12 11:17:35 EDT
(In reply to comment #14)
> I also have the following messages on my 64 bit Red Hat directory server:
> # grep lib /var/log/messages
> Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/liblogin.so.2:
> /usr/lib/sasl2/liblogin.so.2: wrong ELF class: ELFCLASS32
> Aug 12 13:11:45 rhds ns-slapd: unable to dlopen
> /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF
> class: ELFCLASS32
> Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/libplain.so.2:
> /usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32
> 
> My problem is that SSL does not seem to work when setting up a LDAP
> synchronization to an active directory machine. Without SSL it works ok.
> If anyone has pointers how to resolve this, that would be very welcome.
>

Those sasl messages are just annoying and should be ignored.  We are working on a way to remove them from the logs.  In addition, they have nothing to do with SSL, so they are not related to any problems you might be having with SSL.

http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Windows_Sync.html
http://directory.fedoraproject.org/wiki/Howto:WindowsSync
general ssl information
http://directory.fedoraproject.org/wiki/Howto:SSL

> More info:
> Installed base: Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)
> 
> # file /usr/sbin/ns-slapd
> /usr/sbin/ns-slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
> for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux
> 2.6.9, stripped
> 
> # ldd /usr/sbin/ns-slapd
>         libslapd.so.0 => /usr/lib64/dirsrv/libslapd.so.0 (0x00002af86dc7d000)
>         libssldap60.so => /usr/lib64/libssldap60.so (0x00002af86df65000)
>         libprldap60.so => /usr/lib64/libprldap60.so (0x0000003f48400000)
>         libldap60.so => /usr/lib64/libldap60.so (0x0000003f47800000)
>         libldif60.so => /usr/lib64/libldif60.so (0x0000003f48000000)
>         libssl3.so => /usr/lib64/libssl3.so (0x00002af86e172000)
>         libnss3.so => /usr/lib64/libnss3.so (0x00002af86e3a5000)
>         libsoftokn3.so => /usr/lib64/libsoftokn3.so (0x00002af86e6e8000)
>         libplc4.so => /usr/lib64/libplc4.so (0x00002af86e942000)
>         libplds4.so => /usr/lib64/libplds4.so (0x00002af86eb46000)
>         libnspr4.so => /usr/lib64/libnspr4.so (0x00002af86ed4a000)
>         libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003f3b600000)
>         libsvrcore.so.0 => /usr/lib64/libsvrcore.so.0 (0x0000003f46c00000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003f28400000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f29000000)
>         libsmime3.so => /usr/lib64/libsmime3.so (0x00002af86ef85000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x0000003f28c00000)
>         libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002af86f1b0000)
>         libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003f31a00000)
>         libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003f3ae00000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003f28000000)
> 
> # rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl
> cyrus-sasl-lib.x86_64
> cyrus-sasl-gssapi.x86_64
> cyrus-sasl-lib.i386
> cyrus-sasl-plain.x86_64
> cyrus-sasl.x86_64
> cyrus-sasl-md5.x86_64
> cyrus-sasl-plain.i386
> 
> # env | grep -i sasl
> # grep -i sasl_path /etc/rc.d/init.d/dirsrv /etc/sysconfig/dirsrv
> /etc/dirsrv/slapd-*/dse.ldif
> #
Comment 16 Nathan Kinder 2010-02-16 13:46:27 EST
I am unable to even get either MozLDAP or OpenLDAP ldapsearch to see ANONYMOUS as a valid SASL mechanism on my Fedora 11 system.  I have confirmed that libanonymous.so exists in the SASL plugin directory and set SASL_PATH manually to ensure that the proper location is being used.

I ran MozLDAP ldapsearch in a debugger and can see that sasl_client_start() returns an errror that there is no worthy mechanism found when trying to use the ANONYMOUS mechanism.  I'm not sure what exactly is required to make this work, but it's not even getting to the point where the server receives the bind attempt.
Comment 17 Nathan Kinder 2010-02-16 16:53:41 EST
After some debugging through the SASL library code, I found that the default secprops set by the libraries disable anonymous and plaintext authentication.  I am now able to get to the same point as this bug report with an error 49 in the access log by setting the secprops to none with mozLDAP ldapsearch:

  ldapsearch -h localhost.localdomain -p 389 -o "mech=ANONYMOUS" -o "secprop=none" -b "" -s base "objectclass=*"

I'll continue to look into this on the server side.
Comment 18 Nathan Kinder 2010-02-16 18:13:57 EST
The problem is that the bind attempt goes into the normal SASL mapping code.  This causes it to do a search for a real entry to map the SASL authid to using a filter of "uid=anonymous".  It seems that we need some special handing for the anonymous SASL mechanism prior to calling the mapping code.

We will also need to perform a check in the normal bind code to reject binds using the SASL anonymous mechanism if anonymous access is disabled on the server.
Comment 19 Nathan Kinder 2010-02-17 13:57:14 EST
Created attachment 394796 [details]
Patch

The SASL ANONYMOUS mechanism was broken since the SASL mapping code
was invoked to map anonymous to a real user entry.  This adds a
special case to the canonify user callback that sets the bind DN
to "" if the ANONYMOUS mechanism is being used.

I also added a check to see if anonymous access is disabled when
we set up the SASL secprops for a connection.  If anonymous access
is disabled, we set a SASL security flag to disallow mechanisms
that would allow anonymous access.
Comment 20 Nathan Kinder 2010-02-17 14:43:42 EST
Thanks for the review!  Pushed to master.

Counting objects: 11, done.
Delta compression using 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.27 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   a7d0c3d..363be33  master -> master

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