[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Resent: Re: dnNormalize2 failed assertion (sasl_regexp?)
I ran into this bug last week, and have been running the fix below
for a couple of days. I'm not totally convinced my fix is correct.
The Cyrus-SASL gssapi plugin calls gss_unwrap and passes the returned
buffer to dnNormalize2. But the buffer is not guarenteed to be NULL
terminated coming out of gss_unwrap.
Here's a diff for my fix:
*** gssapi.c.orig Thu Sep 19 14:37:10 2002
--- gssapi.c Thu Feb 6 13:09:51 2003
***************
*** 957,968 ****
if (output_token->length > 4) {
int ret;
ret = params->canon_user(params->utils->conn,
! ((char *) output_token->value) + 4,
! (output_token->length - 4) * sizeof(char),
SASL_CU_AUTHZID, oparams);
if (ret != SASL_OK) {
sasl_gss_free_context_contents(text);
return ret;
--- 957,982 ----
if (output_token->length > 4) {
int ret;
+ char *dnbuf;
+ int dnbuflen;
+
+ dnbuflen = output_token->length - 4;
+ dnbuf = (char *)text->utils->malloc( dnbuflen * sizeof(char));
+
+ if(!dnbuf) {
+ gss_release_buffer(&min_stat, output_token);
+ return ret;
+ }
+ memmove (dnbuf, (char *)(output_token->value + 4), dnbuflen * sizeof(char));
+ dnbuf[dnbuflen] = '\0';
ret = params->canon_user(params->utils->conn,
! dnbuf,
! dnbuflen * sizeof(char),
SASL_CU_AUTHZID, oparams);
+ text->utils->free(dnbuf);
+
if (ret != SASL_OK) {
sasl_gss_free_context_contents(text);
return ret;
>
> --U2AV99o4bq1UPJQr
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> * Pierangelo Masarati (ando@sys-net.it) wrote:
> > The assert is there to trap situations like this. If you don't
>
> Yet everything seems to work fine without it, that doesn't make a whole
> lot of sense to me.
>
> > like it, compile with -DNDEBUG. The strlen MUST work because
> > all the dn handling does terminate strings with '\0', so the assert
> > MUST succeed or something mucked with the DN in an erroneous manner
> > (as in this case: who put the '\b' there?). I suggest you let alone
> > the asserts and try to find out who's playing with the DN strings.
>
> I believe that something just isn't putting the NULL there, and I
> suspect it may be SASL. I havn't got a debugging version of SASL around
> atm unfortunately so I'm not sure. A backtrace looks like this though:
>
> (gdb) bt
> #0 slap_sasl_getdn (conn=3D0x4051f0c8, id=3D0x8143614 "dn:uid=3Dsfrost,cn=
> =3DSNOWMAN.NET,cn=3Dgssapi,cn=3Dauth\024\b\021", len=3D46, user_realm=3D0x8=
> 151088 "SNOWMAN.NET",=20
> dn=3D0xbf3ff7c4, flags=3D4) at /data1/sfrost/debs/openldap21/openldap21=
> -2.1.12/servers/slapd/sasl.c:308
> #1 0x0808b643 in slap_sasl_canonicalize (sconn=3D0x81416f0, context=3D0x40=
> 51f0c8, in=3D0x8143614 "dn:uid=3Dsfrost,cn=3DSNOWMAN.NET,cn=3Dgssapi,cn=3Da=
> uth\024\b\021",=20
> inlen=3D46, flags=3D2, user_realm=3D0x8151088 "SNOWMAN.NET", out=3D0x81=
> 42000 "", out_max=3D256, out_len=3D0x8141f5c)
> at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/sasl.c=
> :855
> #2 0x400f81e7 in _sasl_canon_user () from /usr/lib/libsasl2.so.2
> #3 0x403ec420 in _init () from /usr/lib/sasl2/libgssapiv2.so.2
> #4 0x4010065e in sasl_server_step () from /usr/lib/libsasl2.so.2
> #5 0x0808c58f in slap_sasl_bind (conn=3D0x4051f0c8, op=3D0x81425a8, dn=3D0=
> xbf3ffa34, ndn=3D0xbf3ffa2c, cred=3D0xbf3ffa0c, edn=3D0xbf3ffa24, ssfp=3D0x=
> bf3ffa04)
> at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/sasl.c=
> :1540
> #6 0x0806c4fb in do_bind (conn=3D0x4051f0c8, op=3D0x81425a8) at /data1/sfr=
> ost/debs/openldap21/openldap21-2.1.12/servers/slapd/bind.c:299
> #7 0x0805374c in connection_operation (ctx=3D0x81412e8, arg_v=3D0x81428c8)=
> at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/connectio=
> n.c:913
> #8 0x4001efb0 in ldap_int_thread_pool_wrapper (xpool=3D0x80eb1a8) at /data=
> 1/sfrost/debs/openldap21/openldap21-2.1.12/libraries/libldap_r/tpool.c:431
> #9 0x40273d53 in pthread_start_thread () from /lib/libpthread.so.0
> #10 0x40273d99 in pthread_start_thread_event () from /lib/libpthread.so.0
> (gdb)
>
> As you can see above, there's other junk off the end this time, and
> that junk gets passed in to slap_sasl_canonicalize. Is that the
> first that ldap sees it? Perhaps it would make sense to just force
> the issue and put a \0 at the end as soon as it's seen? Maybe I'll
> find some time to build a debugging version of SASL and see if I can
> figure it out.
>
> Stephen
>
>
> --U2AV99o4bq1UPJQr
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQE+Qpz6rzgMPqB3kigRAkgzAJ96P3r1J5ZqUhbjHM26GeUGcAyOOwCfTjNf
> BiGs+dDFCPQt/teTfSQukaQ=
> =0kpM
> -----END PGP SIGNATURE-----
>
> --U2AV99o4bq1UPJQr--
>