[cifs-protocol] [MS-SMB2] Selective Signing of ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO requests - TrackingID#2406060040007612

[Jones Syue 薛懷宗]

> Thanks for digging in further and I can assure you that I appreciate 
> the bluntness. Just to clarify, is your concern that 3.2.4.1.1 signing 
> conditions do not cover all conditions where Windows signs the 
> FSCTL_QUERY_NETWORK_INTERFACE_INFO request? If so, what condition is not 
> covered?
> Or, is the concern that " Windows-based clients do not selectively sign 
> requests" from behavior note 104 should be more specific to say
> " Windows-based clients do not selectively sign requests beyond what 
> is described in this document"?

Thank you Kristian for kind feedback! 
Let me take earilier thread with wireshark captures as an example, it is
Windows-based env (ws2022 oprerates as server, ws2016 operates as client),
through wireshark packet captures there are two ioctl requests with two 
CtlCode FSCTL_QUERY_NETWORK_INTERFACE_INFO and FSCTL_DFS_GET_REFERRALS,
Windows-base client seems to be biased to sign the former one, and the
latter one is not signed: 
1. No. 35478 signature is none zeros, means Windows-based client signs 
   this Ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO request.
2. No. 35480 signature is all zeros, means Windows-based client does not 
   sign this Ioctl FSCTL_DFS_GET_REFERRALS request.
   
Per my test with different Windows-based clients, including
ws2012/ws2012r2/ws2016/ws2019/ws2022, it looks like Windows-based clients
always sign the Ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO request, this 
behavior looks good to me.
However my concern is this behavior is not explicitly mentioned in 
[MS-SMB2] so it is a not clear to me, and i am looking forward to having 
this behavior document in [MS-SMB2] :)

Consider the No. 35476, Windows-based client signs Tree Connect request,
this behavior is explicitly documented in [MS-SMB2] so this looks clear to
me[1][2], so i am expecting something like 'client MUST sign Ioctl 
FSCTL_QUERY_NETWORK_INTERFACE_INFO request' could be mentioned in [MS-SMB2]
too.

No.  |Time      |Prot|Signature                       |Info
-----+----------+----+--------------------------------+----
35467 16:47:09.9 SMB                                   Negotiate Protocol Request
35468 16:47:09.9 SMB2 00000000000000000000000000000000 Negotiate Protocol Response
35469 16:47:09.9 SMB2 00000000000000000000000000000000 Negotiate Protocol Request
35470 16:47:09.9 SMB2 00000000000000000000000000000000 Negotiate Protocol Response
35472 16:47:09.9 SMB2 00000000000000000000000000000000 Session Setup Request, NTLMSSP_NEGOTIATE
35473 16:47:09.9 SMB2 00000000000000000000000000000000 Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE
35474 16:47:09.9 SMB2 00000000000000000000000000000000 Session Setup Request, NTLMSSP_AUTH, User: \administrator
35475 16:47:09.9 SMB2 73182d37759c7741ae0caced9ef04185 Session Setup Response
35476 16:47:09.9 SMB2 ec1d8a66ebea6120e5f8c44be2ba0dc4 Tree Connect Request Tree: \\${MY_IP}\IPC$
35477 16:47:09.9 SMB2 ad4572986b7fae36168ea18c87bb8a9b Tree Connect Response
35478 16:47:09.9 SMB2 d31c1cb4e3ca5df3766faf76a3b6da8a Ioctl Request FSCTL_QUERY_NETWORK_INTERFACE_INFO
35479 16:47:09.9 SMB2 790b171573367693323aa73ddf4de49f Ioctl Response FSCTL_QUERY_NETWORK_INTERFACE_INFO
35480 16:47:09.9 SMB2 00000000000000000000000000000000 Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \${MY_IP}\ramdisk
35482 16:47:09.9 SMB2 00000000000000000000000000000000 Ioctl Response, Error: STATUS_FS_DRIVER_REQUIRED


[1] 3.2.4.1.1 Signing the Message
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/973630a8-8aa1-4398-89a8-13cf830f194d

[2] 3.3.5.7 Receiving an SMB2 TREE_CONNECT Request
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/652e0c14-5014-4470-999d-b174d7b2da87
If Connection.Dialect is "3.1.1" and Session.IsAnonymous and 
Session.IsGuest are set to FALSE and the request is not signed or not 
encrypted, then the server MUST disconnect the connection.

--

Regards,
Jones Syue | 薛懷宗
QNAP Systems, Inc.