ntlmssp errors against El Capitan's SMB Server

Jeremy Allison jra at samba.org
Mon Aug 29 22:45:53 UTC 2016

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 " With Extended Session Security".

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 ?

More information about the samba-technical mailing list