Disabling SMB1 by default

[David Mulder]

> 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.
>
> 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:
https://blogs.technet.microsoft.com/staysafe/2017/05/17/disable-smb-v1-in-managed-environments-with-ad-group-policy/
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.
Are we really ready to disable dialects below 3.0 by default?
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.
>> at the lowest supported and moves up. That's how the protocol is defined.
> Again, not exactly. Servers simply select the highest mutually supported dialect.
> There is no "move up" or "move down", SMB2_NEGOTIATE is a single exchange.
I specifically meant the multi-protocol negotiate, moving from a SMB1
negotiate to SMB2, exactly as you've stated. You've just explained it
much more elegantly :)
>
> The protocol specification is here:
> 	https://technet.microsoft.com/en-us/windowsserver/cc246482.aspx
>
> Tom.
>
>
>> So, enabling SMB3 by default will allow clients to negotiate up to SMB3
>> if supported, but will also continue to support older versions.
>>
>> On 06/20/2017 06:01 AM, Andreas Hasenack via samba-technical wrote:
>>> On Mon, Jun 19, 2017 at 8:14 PM, Jeremy Allison <jra at samba.org> wrote:
>>>
>>>> On Tue, Jun 20, 2017 at 10:20:07AM +1200, Andrew Bartlett via
>>>> samba-technical wrote:
>>>>> On Mon, 2017-06-19 at 15:39 +0200, Stefan Metzmacher via samba-
>>>>> technical wrote:
>>>>>> Hi Andreas,
>>>>>>
>>>>>>> we recently had a bug filed against Ubuntu [1] requesting that we
>>>> disable
>>>>>>> the SMB1 protocol by default. That is part of a larger campaign [2]
>>>> to get
>>>>>>> rid of SMB1 entirely.
>>>>>>>
>>>>>>> Has there been any discussion among Samba developers to change the
>>>> default
>>>>>>> client and server min protocol level to SMB2? Would you consider
>>>> making
>>>>>>> such a change?
>>>>>> We're recently discussed changing 'client max protocol = SMB3' so
>>>>>> that smbclient and other utilities work against servers
>>>>>> with disabled SMB1 by default.
>>>>>>
>>>>>> We hope to get this into 4.7, but there's only about 3 weeks
>>>>>> left to make this change (until 4.7.0rc1 is branched from master),
>>>>>> so it's not sure if such a change will make it into 4.7.0 (released
>>>>>> in September).
>>>>> I had the dates as giving us 2 weeks.  Yes, there isn't much time.
>>>> Yeah, that's too short a time to do anything really. IMHO we
>>>> just need to help people on the list to turn what they can
>>>> off themselves for now, and work on how to do the migration
>>>> properly over the next year or so.
>>>>
>>> What is the big issue with allowing the client to try SMB3 first? Won't it
>>> fallback to SMB2, then NT1, and so on?
>>>
>>> Won't many server admins have disabled SMB1 in their windows servers after
>>> the wannacry attack?
>>>
>> --
>> David Mulder
>> SUSE Labs Software Engineer - Samba
>> dmulder at suse.com
>> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB
>> 21284 (AG Nürnberg)
>>

-- 
David Mulder
SUSE Labs Software Engineer - Samba
dmulder at suse.com
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)