ntlmssp errors against El Capitan's SMB Server

[Jeremy Allison]

On Sun, Aug 28, 2016 at 04:37:43PM +0200, Christian Ambach wrote:
> Am 26.08.16 um 01:56 schrieb Jeremy Allison:
> 
> > Trouble is the server is saying it *does* support the NTLMSSP_NEGOTIATE_SIGN
> > flag in the reply.
> > 
> > Can you get a Windows 8 or above client capture trace connecting to
> > this same server to see "what windows does (tm)".
> 
> Windows 7 and Windows 10 happily finish connecting, see attach pcap.
> I have run git bisect and it pointed me to commit 0d641ee36ae2c.
> CVE-2016-2110: auth/ntlmssp: implement new_spnego support including MIC
> generation (as client)
> 
> So the rules were tightened because of Badlock. Maybe too tight?
> 
> I have also found an Ubuntu bug about the same:
> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1579540
> 
> Setting ntlmssp_client:force_old_spnego = yes to helps,
> but this will then affect all client connections.
> 
> Which spec applies here to indicate that the server must supply a signature?

It's the NTLMSSP one I think.

[MS-NLMP].pdf. Check out "3.4.4.2 With Extended Session Security".

When Extended Session Security (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY) is
negotiated and session security (NTLMSSP_NEGOTIATE_SIGN or NTLMSSP_NEGOTIATE_SEAL) is
negotiated, the message signature for NTLM with extended session security is a 16-byte value that
contains the following components, as described by the NTLMSSP_MESSAGE_SIGNATURE structure:
....

Our code says:

                        if (have_sign && new_spnego) {
                                spnego_state->needs_mic_check = true;
                                spnego_state->needs_mic_sign = true;
                        }

and the server is requesting negotiate signing, so we are
insisting on the mic check (as we should).

I think the Windows client is buggy here by not checking the
signature returned by the server - the question is should we match
that ?

Or have an option to match that ?