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

[Kristian Smith]

Hi Jones,

I've been looking into the concerns that you outlined in your last email and it does appear that there is an inconsistency in the way the client signs most other requests. I was able to repro a trace where many SMB 3.x requests are unsigned (including FSCTL_DFS_GET_REFERRALS as you've shown). I am conducting some debugging to determine where these decisions are occurring in the code. Once I've come to a conclusion, I'll reach out with my findings.

Thanks for your patience.

Regards,
Kristian Smith
Support Escalation Engineer | Microsoft(r) Corporation
Office phone: +1 425-421-4442
Email: kristian.smith at microsoft.com
-----Original Message-----
From: Jones Syue 薛懷宗 <jonessyue at qnap.com>
Sent: Friday, June 7, 2024 1:45 AM
To: Kristian Smith <Kristian.Smith at microsoft.com>; cifs-protocol at lists.samba.org
Cc: Microsoft Support <supportmail at microsoft.com>
Subject: [EXTERNAL] Re: [MS-SMB2] Selective Signing of ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO requests - TrackingID#2406060040007612

> 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.