Issues bringing 'new SPENGO' to MIT Kerberos 1.8 builds

[Andrew Bartlett]

Metze,

I've been working to fix the issues with the s3-rpc-gensec branch that I
proposed to you last week.  This iteration of that branch replaces
Simo's cli_spengo code with gensec_spengo. 

However this fails when attempting to sign the mechList on the client,
after testing to see if the connection requires 'new SPENGO' (ie, with
the signed mechList). 

The key difference between the SPENGO implementations is that Simo's
code never created the mechListMic on the client, never called
gss_krb5_export_lucid_sec_context() and only checked nechListMic on the
server if it was present.  That is why it fails with this switch over. 

The issue is that the call to gensec_have_feature(sub_sec_context,
GENSEC_FEATURE_NEW_SPNEGO) calls gse_init_lucid() and then
gss_krb5_export_lucid_sec_context().  If successful, it would tell us if
we should be generating and checking those signatures.

auth/gensec/spengo.c:
if (NT_STATUS_IS_OK(nt_status)
    && spnego.negTokenTarg.negResult != SPNEGO_ACCEPT_COMPLETED) {
	new_spnego = gensec_have_feature(spnego_state->sub_sec_security,
					 GENSEC_FEATURE_NEW_SPNEGO);
}
if (NT_STATUS_IS_OK(nt_status) && new_spnego) {
	nt_status = gensec_sign_packet(spnego_state->sub_sec_security,
				       out_mem_ctx,
				       spnego_state->mech_types.data,
				       spnego_state->mech_types.length,
				       spnego_state->mech_types.data,
				       spnego_state->mech_types.length,
				       &mech_list_mic);
  ...
}

source3/librpc/crypto/gse.c:
maj_stat = gss_krb5_export_lucid_sec_context(&min_stat,
					     &gse_ctx->gssapi_context,
					     1, &ptr);


This comes up now, and only in with MIT Kerberos (and therefore only in
the autoconf build) because while in Heimdal
gss_krb5_export_lucid_sec_context() is safe, in MIT kerberos it
destroyed (free and NULLed out) the gssapi context supplied as an
argument.  Naturally, the gensec_sign_packet() fails once the gssapi
context has been destroyed. 

This didn't come up with the session setup work as we have not converted
the client, but I'm not sure why the smb encryption client didn't
trigger this. 

Anyway, I attempted to work around the issue with the attached patch,
exporting the context and re-importing it to run
gss_krb5_export_lucid_sec_context(), but while it passes on MIT krb5 1.9
locally, on sn-devel it segfaults inside libkrb5:

==26500== Invalid read of size 4
==26500==    at 0x5F6BC2E: profile_ser_size (in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5F55228: ??? (in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5CE21B4: ??? (in /usr/lib/libgssapi_krb5.so.2.2)
==26500==    by 0x5CD5EB0: ??? (in /usr/lib/libgssapi_krb5.so.2.2)
==26500==    by 0x5CCA556: gss_export_sec_context
(in /usr/lib/libgssapi_krb5.so.2.2)
==26500==    by 0x847F74: gse_init_lucid (gse.c:614)
==26500==    by 0x8496EB: gensec_gse_have_feature (gse.c:1190)
==26500==    by 0x2BF61E: gensec_have_feature (gensec.c:395)
==26500==    by 0x2C5A30: gensec_spnego_update (spnego.c:1079)
==26500==    by 0x2C6203: gensec_spnego_update_wrapper (spnego.c:1314)
==26500==    by 0x2BF0EF: gensec_update (gensec.c:220)
==26500==    by 0x842066: rpc_pipe_bind_step_one_done (cli_pipe.c:1698)
==26500==  Address 0x8c67bec is 204 bytes inside a block of size 206
alloc'd
==26500==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==26500==    by 0x5F69801: ??? (in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5F69BF1: profile_open_file
(in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5F6BFFB: profile_init (in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5F6374A: ??? (in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5F6387D: krb5_os_init_context
(in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x5F4368D: ??? (in /usr/lib/libkrb5.so.3.3)
==26500==    by 0x8473E0: gse_context_init (gse.c:208)
==26500==    by 0x8475A8: gse_init_client (gse.c:260)
==26500==    by 0x848ED2: gensec_gse_client_start (gse.c:941)
==26500==    by 0x2C12A5: gensec_start_mech (gensec_start.c:632)
==26500==    by 0x2C142E: gensec_start_mech_by_ops (gensec_start.c:663)
==26500== 

Can either of you think of any other way to determine if new SPNEGO is
needed?  Otherwise, I think we may need to upgrade sn-devel and restrict
MIT Kerberos to 1.9 or newer, or perhaps the encryption types used by
gensec_gse (and avoid setting our server account as supporting AES) to
avoid new SPNEGO being negotiated when running MIT Kerberos 1.8. 

Thanks,

Andrew Bartlett

(I've updated s3-rpc-gensec with this patch)

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-librpc-Ensure-that-the-gssapi-context-survives-th.patch
Type: text/x-patch
Size: 4445 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120208/d2af8960/attachment.bin>