Disabling SMB1 by default

[Tom Talpey]

> -----Original Message-----
> From: David Mulder [mailto:dmulder at suse.com]
> Sent: Tuesday, June 20, 2017 9:16 AM
> To: Tom Talpey <ttalpey at microsoft.com>
> Cc: samba-technical at lists.samba.org; Andreas Hasenack
> <andreas at canonical.com>
> Subject: Re: Disabling SMB1 by default
> 
> 
> > Incorrect, there are two flavors of negotiate, the downward-compatible
> SMB1-style,
> > and the SMB2-only style. The style is chosen by the client, and typically if
> SMB1 is
> > not supported there, the SMB2-only style will be sent.
> I meant that with SMB1 enabled in the samba client, it will always
> attempt SMB1 first with a multi-protocol negotiate.

Interesting. The Windows client will check to see if it has previously connected
to the server since the boot epoch, and even if SMB1 is enabled it will jump
straight to SMB2-only negotiate if a previous SMB2 negotiate succeeded. If
SMB1 is disabled of course it does SMB2-style unconditionally.

> > The server then selects the highest mutually-supported dialect, and responds.
> If
> > the selected dialect is SMB1, the SMB1 negotiate response is sent. If SMB2,
> the
> > SMB2 negotiate response is sent.
> >
> > The risk of supporting SMB1 in the client is that a MTIM can simply
> downgrade
> > the connection to the vulnerable SMB1 flavors, even when the connection
> would
> > support a higher version. So, completely disabling the SMB1 support in the
> client
> > is strongly recommended.
> More details here:
...
> The risk of a downgrade attack is certainly a good reason to raise the
> default minimum dialect.
> But in order to avoid MITM attacks, we really would need to raise the
> minimum dialect to 3.0 to support secure negotiation (the spec says 3.0,
> but I seem to recall it actually works in 2.10 also), not just disable SMB1.

Secure negotiate has two flavors, in dialect 3.0 and 3.0.2 it was via an FSCTL,
and in 3.1.1, via "negotiate contexts" aka "preauth integrity". The 3.x client
performs the validation regardless of which SMB2/3 dialect was negotiated,
specifically for the MITM downgrade possibility. A 2.x downgrade can still
be detected due to the FSCTL requiring signing.

It's subtle, but the point is that it's not about the dialect that's actually negotiated,
it's about the capabilities of both ends, and how they mutually determine there
is not a MITM. I agree that the 3.1.1 dialect is the best, but any 3.x dialect is
acceptable, and 2.x is still supported of course.

> Are we really ready to disable dialects below 3.0 by default?

I don’t recommend that. SMB2.x is still widely deployed, and SMB3.x is not
supported on many such servers (for Microsoft products, SMB3.x requires at
least Win8/WS2012). Windows is not considering to disable 2.x. 

> Even then, secure negotiation hasn't been implemented correctly in most
> clients, so pre-auth integrity would be better, and it's only available
> in 3.1.1.

Correct, but I strongly suggest addressing shortcomings in the clients you mention.
"Most"? Can you elaborate?

Tom.