RE: OpenLDAP uses crypt() of OpenSSL instead of system libraries (ITS#2123)

[hyc@highlandsun.com]

Also please understand, this is not merely a question of adhering to abstract
"good programming" principles. I spend a great deal of energy tracking down
problems that arise, tracing them to their root cause. When the problem is in
OpenLDAP we fix it in OpenLDAP. When the problem is in Cyrus SASL or Berkeley
DB or elsewhere, I fix it there when it's in my power to do so. You have to
trace problems to their source, this is the only way to fix bugs, period.

Let me paint a picture for you, where we adopt the band-aid hack approach.
Now we have a libldap that drags in libssl/libcrypto, and our libldap happens
to be linked into nss_ldap and pam_ldap. Think about what happens when a
computer system configured with both pam_unix and pam_ldap tries to
authenticate a user. When pam_ldap loads into the address space, it brings
OpenSSL's version of crypt along with it. We no longer have any control over
load ordering in this scenario, because the native system's libpam
dynamically loaded the PAM modules. Which version of crypt() will pam_unix
see? Will it be able to properly authenticate legitimate local users? The
question is unanswerable, using your quick hack approach, because now it
depends on the order that pam_ldap and pam_unix are stacked in pam.conf. And
*that* order is significant for security policy reasons, and is
non-negotiable.

When you accept quick hacks in your code, all you do is make things worse
down the road. The whole point of having Open Source is that you are
empowered to fix problems correctly, without needing to resort to bad hacks
that can't really solve the problem.

The patch to the OpenSSL library is a matter of changing one line from a "#if
defined(FOO)" to "#if 0", turning off the offending function. It takes maybe
two seconds to fix this problem, and those two seconds will save
who-knows-how-many hours chasing down misbehaviors in all the applications
that knowingly or inadvertently rely upon the library.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: Kervin L. Pierre [mailto:kervin@blueprint-tech.com]
> Sent: Thursday, October 03, 2002 1:39 PM
> To: hyc@highlandsun.com
> Cc: openldap-its@OpenLDAP.org; ast@domdv.de
> Subject: Re: OpenLDAP uses crypt() of OpenSSL instead of system
> libraries (ITS#2123)
>
>
> I know I'm going to annoy some people by saying this, I apologize in
> advance.  But this is definately an OpenLDAP bug.
>
> It is entirely reseanable for two libraries to export the
> same function
> name.  It is up to OpenLDAP's build environment to make sure
> it gets the
> function it expects.  Maybe by specifying the library link order.
>
> There should be an easier way to do this that to patch OpenSSL.
>
> How about the solution he suggested? ie. -lcrypt before
> -lcrypto in the
> makefiles
>
> We could also specify -lc before -lcrypto for platforms without a
> libcrypt maybe.
>
> --Kervin
>
>
> hyc@highlandsun.com wrote:
> > The OpenSSL library is defective. See the FAQ-o-Matic.
> > http://www.openldap.org/faq/data/cache/185.html
> >
> > This is not an OpenLDAP bug, this issue will be closed.
> >
> >   -- Howard Chu
> >   Chief Architect, Symas Corp.       Director, Highland Sun
> >   http://www.symas.com               http://highlandsun.com/hyc
> >   Symas: Premier OpenSource Development and Support
> >
> >
> >>-----Original Message-----
> >>From: owner-openldap-bugs@OpenLDAP.org
> >>[mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of ast@domdv.de
> >>Sent: Thursday, October 03, 2002 3:29 AM
> >>To: openldap-its@OpenLDAP.org
> >>Subject: OpenLDAP uses crypt() of OpenSSL instead of system
> libraries
> >>(ITS#2123)
> >>
> >>
> >>Full_Name: Andreas Steinmetz
> >>Version: 2.1.5
> >>OS: Linux 2.4
> >>URL:
> >>Submission from: (NULL) (217.229.56.110)
> >>
> >>
> >>Description:
> >>
> >>OpenLDAP links against OpenSSL (-lcrypto) without prior
> >>linking against the
> >>proper system library (-lcrypt) so the crypt() function of
> >>OpenSSL is used
> >>instad of the system crypt() function.
> >>
> >>Problem:
> >>
> >>Unfortunately the OpenSSL crypt() function does not handle
> >>MD5 passwords as does
> >>the system crypt() function (part of glibc 2.2.5). Thus
> >>transparent migration to
> >>OpenLDAP from Shadow or NIS will fail for all more modern
> >>installations as the
> >>user passwords are not processed correctly.
> >>
> >>Solution:
> >>
> >>Assert to link against -lcrypt prior to linking against
> >>-lcrypto on systems
> >>which do have an explicit crypt library, i.e. include
> >>LUTIL_LIBS for linking
> >>(seems to be defined but ignored) and do it before
> including TLS_LIBS.
> >>
> >>
> >
> >
> >
> >
>
>