[Patches] s3:smbd: unimplement FSCTL_VALIDATE_NEGOTIATE_INFO with "server max protocol = SMB2_02" (bug #12772)

[Tom Talpey]

> -----Original Message-----
> From: Stefan Metzmacher [mailto:metze at samba.org]
> Sent: Monday, June 26, 2017 6:01 PM
> To: Tom Talpey <ttalpey at microsoft.com>
> Subject: Re: [Patches] s3:smbd: unimplement
> FSCTL_VALIDATE_NEGOTIATE_INFO with "server max protocol = SMB2_02"
> (bug #12772)
> 
> Hi Tom,
> 
> >> here're patches which fix a problem that happens
> >> if "server max protcol = SMB2_02" is used and the client
> >> is able to handle SMB3 with FSCTL_VALIDATE_NEGOTIATE_INFO.
> >>
> >> It's not possible for an SMB2_02 server to implement
> >> FSCTL_VALIDATE_NEGOTIATE_INFO correctly, as it doesn't
> >> have the information from a SMB2 Negotiate Request available,
> >> as the client started with SMB1 Negotiate.
> >
> > I don't fully understand the issue. If SMB 2.0.2 is negotiated via an SMB2-style
> > exchange, the capabilities are explicit. If it were negotiated via SMB1 "2.002",
> > they're effectively zero. Your change appears to deny SMB 2.0.2-era clients?
> > (which all initiate via SMB1, and accept "2.002")
> 
> The situation is this:
> 
> The client:
> - is able to negotiate SMB 3 (any SMB3 version).
> - has a client a client guid (efc896ce-5ab7-11e7-9382-c7bbed748536)
> - supported capabilities 0x41 (SMB2_CAP_DFS | SMB2_CAP_ENCRYPTION)
> - security mode 0x3 (SMB2_NEGOTIATE_SIGNING_REQUIRED|
>   SMB2_NEGOTIATE_SIGNING_ENABLED)
> - Dialects 0x0202, 0x0210, 0x030, 0x0302
> 
> The server:
> - Is configured with "server max protocol = SMB2_02",
>   so the maximum it pretends to support is SMB 2.02.
> 
> Then the client sends an SMB1 Negprot with "SMB 2.002" and "SMB 2.???".

Ok, so one good thing about this is that the client will no longer send an
SMB1 negotiate if it disables SMB1. Which we're all strongly recommending.

> The server responses with an SMB2 Negotiate Response with dialect
> 0x0202 selected.
> 
> In this cases the servers client_guid, client_capabilities,
> client_security_mode and client_dialects are all 0,NULL or empty.
> 
> Now the client tries to check if someone downgraded the connection
> and sends an FSCTL_VALIDATE_NEGOTIATE_INFO with:
> - client guid (efc896ce-5ab7-11e7-9382-c7bbed748536)
> - supported capabilities 0x41 (SMB2_CAP_DFS | SMB2_CAP_ENCRYPTION)
> - security mode 0x3 (SMB2_NEGOTIATE_SIGNING_REQUIRED|
>   SMB2_NEGOTIATE_SIGNING_ENABLED)
> - Dialects 0x0202, 0x0210, 0x030, 0x0302
> 
> The server detects that these values doesn't match the values
> zero values stored on it's connection state and disconnects the client.

Ah - of course, it's the *server* that disconnects. Now I understand the
scenario. Ok, I agree with your solution!

> I'm able to reproduce this with a Windows client or "smbclient"
> against Samba 4.* configured with "server max protocol = SMB2_02".
> 
> The problem doesn't happen against Windows Vista or Samba 3.6,
> they also only offer SMB 2.02, but they don't support
> FSCTL_VALIDATE_NEGOTIATE_INFO and just return NT_STATUS_FILE_CLOSED,
> which is the indication for the client that the server really only
> supports SMB 2.02 (or maybe SMB 2.10).
> 
> Now you could say it's stupid to run a server that has SMB3 implemented
> using "server max protocol = SMB2_02". In theory I'd agree, but the
> problem is that there is a bug in Windows (I think 2012 and 2012R2),
> that a immediate reconnect to a server doesn't work if the negotiated
> dialect jumps from SMB 2 to SMB 3. The client somehow gets the session
> key for the SMB3 signing wrong. If you use "net use /del" wait something
> like 30 seconds and reconnect it works fine using SMB3.
> This is fixed in the Windows 10 client, but it's a problem for users of
> older Versions.

Yes, it's unfortunate but a fairly high bar is required to justify patches to
downlevel systems. By the way, if you disagree with any such decision, it's
possible to discuss it further and potentially change.

> That's why some Samba vendors try to avoid changing the max protocol
> during an update from Samba 3.6 to a recent version, e.g. 4.6.

Which, by the way, is great input. Thanks.

Tom.



> 
> I hope the above explains it.
> 
> Thanks for the feedback!
> metze