openldap client GSSAPI authentication segfaults in fbsd8stable i386

[Jeremy Chadwick]

On Tue, Jul 13, 2010 at 10:10:25PM +0200, Henrik /KaarPoSoft wrote:
> Dear All,
> 
> I have a problem: ldapsearch results in "Segmentation fault" under
> openldap-2.4.23 with cyrus-sasl-2.1.23.
> 
> A thread for similar issues was started by George Mamalakis back in
> february:
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html
> but I find no solution / conclusion from this thread, hence I post here...
> 
> I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with
> freebsd-update, and ports updated with "portsnap fetch update".
> 
> Kerberos installed from packages, configured, and seems to work OK.
> 
> It seems that there are no package for openldap server with
> GSSAPI/SASL, so I have build and installed cyrus-sasl2,
> openldap24-server (with sasl configured) and openldap24-sasl-client
> from ports.
> 
> Those are the port versions:
> # $FreeBSD: ports/security/cyrus-sasl2/Makefile,v 1.141 2009/08/02
> 19:35:25 mezz Exp $
> # $FreeBSD: ports/net/openldap24-server/Makefile,v 1.181 2010/07/01
> 19:04:42 delphij Exp $
> 
> According to the distinfo files, those are the upstream versions:
> openldap-2.4.23
> cyrus-sasl-2.1.23
> which, as far as I can see, are the latest stable.
> 
> Trying LDAP I get a segfault:
> 
> $ ldapsearch
> SASL/GSSAPI authentication started
> Segmentation fault (core dumped)

I know absolutely nothing about GSSAPI and have very little experience
with LDAP.  But I'll take a shot at this:

> Here is the backtrace from gdb:
> 
> #0  0x283225c7 in free () from /lib/libc.so.7
> #1  0x28654b42 in gss_release_buffer () from /usr/lib/libgssapi.so.10
> #2  0x28654512 in gss_release_name () from /usr/lib/libgssapi.so.10
> #3  0x28650e69 in gss_init_sec_context () from /usr/lib/libgssapi.so.10
> #4  0x28648a0f in gssapi_client_mech_step () from
> /usr/local/lib/sasl2/libgssapiv2.so.2
> #5  0x280ef4b1 in sasl_client_step () from /usr/local/lib/libsasl2.so.2

The problem looks like it may be that gss_release_buffer() is passing
free() an invalid pointer (which may be coming from other functions up
the stack).  Without debugging symbols enabled this is a bit difficult
to track down.

Since free() is in the call stack, I would say buffer->value contains a
pointer that is incorrect (e.g. out of process addressing scope).  It
could also be that buffer itself points to something invalid.

> /var/log/messages has:
> slapd[1146]: OTP unavailable because can't read/write key database
> /etc/opiekeys: Permission denied
> kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped)
> 
> The first message is from the LDAP server. Even if it has some
> problem, it should not lead the client to segfault.

I agree.

If I was to build a test box from scratch, can you tell me how to set up
all the necessary software/etc. to mimic your environment so that I
could try to reproduce this?  Reviewing the source isn't enough, I'd
have to actually build a debug version of libgssapi to track it down.

Alternatively I can try to step you through how to debug this using gdb,
but again, lack of debugging symbols makes this annoying.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |