openldap client GSSAPI authentication segfaults in
fbsd8stablei386
Jeremy Chadwick
freebsd at jdc.parodius.com
Sun Jul 18 03:08:10 UTC 2010
On Sat, Jul 17, 2010 at 07:38:19PM -0700, Jeremy Chadwick wrote:
> On Sun, Jul 18, 2010 at 01:37:06AM +0300, Reko Turja wrote:
> >
> > >Can you try reproducing the issue on 8-STABLE?
> > >
> > >I recently submitted a Heimdal patch against 8.1-STABLE and
> > >9.0-CURRENT that resolves some libgssapi-related issues:
> > >
> > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454
> > >
> > >The patch breaks ABI, so you'll have to rebuild libgssapi-dependent
> > >applications.
> >
> > When linking cyrus-sasl2 against gssapi library from either the
> > 1.0.1 official port or the inofficial 1.2.1 patchset cyradm works as
> > expected and it logs a message from gssapi/kerberos telling that no
> > KDC's are available - which is to be expected on a system that isn't
> > using gssapi/kerberos in authenticating.
> >
> > So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday
> > the 5th is clearly some kind of regression as system gsslib doesn't
> > seem to recognize the mech used or segfaults.
> >
> > Benjamin, can you clarify how to apply your patch against the source
> > tree - I tried 'patch < the_patchset.diff' in /usr/src but it just
> > created a bunch of files in the /usr/src which I think isn't the
> > intention.
>
> Those following this thread will be happy to hear that I'm able to
> reproduce the problem on the i386 test box:
>
> testbox# pkg_info
> cyrus-imapd-2.3.16_1 The cyrus mail server, supporting POP3 and IMAP4 protocols
> cyrus-sasl-2.1.23 RFC 2222 SASL (Simple Authentication and Security Layer)
> db41-4.1.25_4 The Berkeley DB package, revision 4.1
> libtool-2.2.6b Generic shared library support script
> perl-5.10.1_1 Practical Extraction and Report Language
> portaudit-0.5.15 Checks installed ports against a list of security vulnerabi
> rsync-3.0.7 A network file distribution/synchronization utility
> vim-lite-7.2.411 Vi "workalike", with many additional features (Lite package
>
> testbox# cyradm localhost
> Segmentation fault (core dumped)
>
> Jul 17 19:35:40 testbox imap[72119]: executed
> Jul 17 19:35:40 testbox imap[72119]: accepted connection
> Jul 17 19:35:46 testbox kernel: pid 72118 (perl5.10.1), uid 0: exited on signal 11 (core dumped)
>
> -rw------- 1 root wheel 4448256 Jul 17 19:35 perl5.10.1.core
>
> (gdb) bt
> #0 free (ptr=0x280861c0) at /usr/src/lib/libc/stdlib/malloc.c:3890
> #1 0x287edce2 in gss_release_buffer (minor_status=0xbfbfe698, buffer=0x280861cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41
> #2 0x287ed6b2 in _gss_mg_error (m=0x28455bc0, maj=851968, min=2) at /usr/src/lib/libgssapi/gss_display_status.c:240
> #3 0x287ea009 in gss_init_sec_context (minor_status=0xbfbfe7a8, initiator_cred_handle=0x0, context_handle=0x28837354,
> target_name=0x285bff60, input_mech_type=0x0, req_flags=58, time_req=0, input_chan_bindings=0x0, input_token=0x0,
> actual_mech_type=0x0, output_token=0xbfbfe790, ret_flags=0xbfbfe7a0, time_rec=0x0)
> at /usr/src/lib/libgssapi/gss_init_sec_context.c:156
> #4 0x287e1aef in gssapi_client_mech_step (conn_context=0x28837350, params=0x2841e480, serverin=0x0, serverinlen=0,
> prompt_need=0xbfbfea70, clientout=0xbfbfea6c, clientoutlen=0xbfbfea68, oparams=0x2846b860) at gssapi.c:1418
> #5 0x283ef591 in sasl_client_step (conn=0x2846b000, serverin=0x0, serverinlen=0, prompt_need=0xbfbfea70, clientout=0xbfbfea6c,
> clientoutlen=0xbfbfea68) at client.c:655
> #6 0x283f0215 in sasl_client_start (conn=0x2846b000, mechlist=0x288878c0 "GSSAPI ", prompt_need=0xbfbfea70, clientout=0xbfbfea6c,
> clientoutlen=0xbfbfea68, mech=0xbfbfea78) at client.c:603
> #7 0x2832ab1a in imclient_authenticate (imclient=0x288b4000, mechlist=0x28887880 "GSSAPI ", service=0x288877e8 "imap",
> user=0x28801754 "", minssf=0, maxssf=10000) at imclient.c:1288
> #8 0x28327131 in XS_Cyrus__IMAP__authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so
> #9 0x2811d2e5 in Perl_pp_entersub () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so
> #10 0x2811b7e5 in Perl_runops_standard () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so
> #11 0x280c20d4 in perl_run () from /usr/local/lib/perl5/5.10.1/mach/CORE/libperl.so
> #12 0x08048944 in main ()
>
> I'll poke more at this.
Problem solved. Same i386 box:
testbox# uname -a
FreeBSD testbox.home.lan 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Sat Jul 17 18:46:34 PDT 2010 root at testbox.home.lan:/usr/obj/usr/src/sys/TESTBOX i386
testbox# ls -l /usr/lib/libgssapi.so*
lrwxr-xr-x 1 root wheel 15 Jul 17 19:47 /usr/lib/libgssapi.so -> libgssapi.so.10
-r--r--r-- 1 root wheel 1702244 Jul 17 19:47 /usr/lib/libgssapi.so.10
testbox# cyradm localhost
Login disabled.
cyradm: cannot authenticate to server with as root
Jul 17 19:48:51 testbox master[72266]: about to exec /usr/local/cyrus/bin/imapd
Jul 17 19:48:51 testbox imap[72266]: executed
Jul 17 19:48:51 testbox imap[72266]: accepted connection
Jul 17 19:48:51 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
Jul 17 19:48:51 testbox kernel: Jul 17 19:48:51 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown)
Jul 17 19:48:51 testbox perl: No worthy mechs found
Jul 17 19:48:51 testbox kernel: Jul 17 19:48:51 testbox perl: No worthy mechs found
I then tested the same patch on amd64 -- it also works. Again, this has
only been tested on RELENG_8.
Methodology for patching/fixing is simple:
cd /usr/src
patch -p0 < /path/to/patch
cd lib/libgssapi
make
make install
Then restart any daemons which link to libgssapi or any of the related
libgssapi_xxx libraries (you can use ldd to determine this). In the
above case, all I had restart was imapd.
You *do not* need to rebuild software which is reliant upon libgssapi;
the function semantics/API hasn't changed, just the code within one of
the functions (gss_release_buffer()). There's no need to bump the
library version number either because of this.
As far as why it's more prevalent on i386 than amd64: a disassembly
would probably help explain that. But to be honest, the last time I
worked with x86 assembly was back in the 386/very early 486 days, and
that was pure protected mode programming (not under *IX). There's
basically little to no chance I'd understand the disassembly here.
Someone else would have to delve into it.
People who have open PRs on this matter -- please feel free to reference
this thread, and/or the below patch, in your PRs. I've also put the
patch up on my website for easy fetching:
http://jdc.parodius.com/freebsd/gss_release_buffer.c.patch
Cheers!
--
| 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 |
--- lib/libgssapi/gss_release_buffer.c.orig 2009-08-03 01:13:06.000000000 -0700
+++ lib/libgssapi/gss_release_buffer.c 2010-07-17 19:47:25.000000000 -0700
@@ -37,7 +37,7 @@
{
*minor_status = 0;
- if (buffer->value)
+ if (buffer->length && buffer->value)
free(buffer->value);
_gss_buffer_zero(buffer);
More information about the freebsd-stable
mailing list