Samba server problem with validate negotiate info fsctl?

[Steve French]

With the kernel patch I recently submitted to list for review, tried
the validate negotiate info fsctl (unsigned) on an smb3.0 mount
against Windows 8.1 server and it failed, dropping the connection
immediately. I repeated it with "sign" mount option and it worked
fine.

Trying the validate negotiate info fsctl against Samba though it
worked fine with signing disabled implying that the server is not
checking to make sure that that request is signed (the validate
negotiate info fsctl is always supposed to be signed right?)

[Tom Talpey]

-----Original Message-----
Sent: Monday, November 18, 2013 6:55 PM
Subject: Samba server problem with validate negotiate info fsctl?
With the kernel patch I recently submitted to list for review, tried the
validate negotiate info fsctl (unsigned) on an smb3.0 mount against Windows
8.1 server and it failed, dropping the connection immediately. I repeated it
with "sign" mount option and it worked fine.
Trying the validate negotiate info fsctl against Samba though it worked fine
with signing disabled implying that the server is not checking to make sure
that that request is signed (the validate negotiate info fsctl is always
supposed to be signed right?)

Indeed yes - and signing the validate negotiate is important to ensure it's not tampered with by a MITM attacker. The MS-SMB2 document makes the client requirement in section 3.2.5.5 (emphasis added):

"If MaxDialect is "3.000" or "3.002", and RequireSecureNegotiate is TRUE, the client MUST validate the SMB2 NEGOTIATE messages originally sent on this connection by sending a *signed* VALIDATE_NEGOTIATE_INFO request as specified in section 2.2.31.4. "

Note that "MaxDialect" is the highest dialect the client is capable of, not necessarily the dialect negotiated on the connection. This too is important, to detect a negotiation downgrade by a MITM. Since the server will sign its response, even a failure can be used to complete the validation.