ntlmssp errors against El Capitan's SMB Server

[Stefan Metzmacher]

Hi Jeremy,

> note the 'ntlmssp_state->new_spnego = true' when timestamp != NULL.
> 
> And it looks like the Windows client doesn't check the
> mechlistMIC in this case, so we might need to losen our
> check also.
> 
> This would also fix the smbclient connecting to the Microsoft
> Azure server problem - that server also only does NTLM and
> doesn't send the mechlistMIC in the ACCEPT_COMPLETED reply.
> 
> Attached is a possible patch, but I'm *really* unsure
> if this is safe w.r.t. downgrade attacks.
> 
> Metze, can you take a look at this and let me know what you
> think ?

The problem I see with this is that client doesn't know
if the server processed the mechListMIC.

Which has implications on:

        if (NT_STATUS_IS_OK(status)) {
                bool reset_full = true;

                gensec_security->child_security =
spnego_state->sub_sec_security;

                reset_full = !spnego_state->done_mic_check;

                status =
gensec_may_reset_crypto(spnego_state->sub_sec_security,
                                                 reset_full);
        }

@Simo: We discussed that the reset_full parameter might not be required,
but I think
these "broken/lazy" servers would be the reason to have it there.

As this problem hopefully only present at the SMB* protocols, which have
their own
signing/encrytion implementations, I'd propose to add a
GENSEC_FEATURE_SMB_STYLE
and allow Jeremy's change only if GENSEC_FEATURE_SMB_STYLE is present.
(We already have GENSEC_FEATURE_DCE_STYLE and GENSEC_FEATURE_LDAP_STYLE
so adding GENSEC_FEATURE_SMB_STYLE would be a similar way to work around
SMB specific
implementation bugs).

What do you think?

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160831/aa280e66/signature.sig>