none
MS-SMB2 Change Notify Response SessionId RRS feed

  • Question

  • Hi

    I've been working on implementing the SMB2 Change Notify request in a custom SMB2 Python library and I've come across and issue when issuing the change notify as a compound request in the create message.

    The issue is that the SMB2 Change Notify is being sent with a SessionId is set to a value of 0xFFFFFFFFFFFFFFFF which wouldn't be an issue normally as in a compound request reply the data is sent under 1 payload. Unfortunately in the case of an SMB2 Change Notify message the packet is sent separate so I cannot validate the signature or decrypt the reply as I can't reliably determine the session id from the reply.

    If I was to send the Change Notify as a single request everything works jut fine, the issue is only a problem when it is a changed request under a related operation.

    When I typically send a compound request to an SMB server I've only ever seen it reply with 1 packet that contains all the responses to each request under that single packet. This is also true for encrypted messages where the reply is a single SMB2 Transform response that once decrypted contain the header and response for all the requests. When it comes to a compound request with an SMB2 Change Notify request I found there are now 2 replies instead of the 1 with the change notify coming separately but still formatted in a way that is found in a chain reply (Chained flag and SessionId as 0xFFFFFFFFFFFFFFFF).

    To show you what I mean here is a Wireshark capture of this in action. You can see that in the case of a compound request with an SMB2 Change Notify message, here is what I'm currently sending to the server



    Subsequently I now get 2 replies back, the first being the reply to the Create and the 2nd a reply to the change notify with STATUS_PENDING.





    You can see that they are 2 separate packets and the SessionId behaviour I've been describing.

    Technically I could just not verify the signature and continue on but that goes against the reason for a signature. The problem is worse when it comes to encryption as the SMB2 Transform header is sent in the 2 TCP packets as a reply where the first contains the proper SessionId and the 2nd contains the SessionId as 0xFFFFFFFFFFFF. So in the case of encryption being used I can't even decrypt the packet to determine what the reply is actually for.

    I could not find any documentation in MS-SMB2 to describe this behaviour and I'm wondering where you can help me track down the proper way to handle this.

    Just as an FYI I'm seeing the same behaviour against a Windows SMB server as well as a Samba server so it leads me to believe it is not a bug.

    Thanks

    Jordan

    Saturday, November 2, 2019 9:52 PM

Answers

  • We have worked through this through email and came to the conclusion that you can lookup the proper Session Id for verification using the Message Id of the response and find the corresponding request's value.

    As for the encryption side, this wasn't an actual issue on Microsoft's SMB implementation but I was seeing the behaviour on Samba only. I will file a bug there for that issue.

    • Marked as answer by jborean93 Wednesday, November 6, 2019 8:32 PM
    Wednesday, November 6, 2019 8:32 PM

All replies

  • Hi Jordan,
    Thank you for this inquiry. One of our engineers will follow-up and assist you with this.
    Thanks,
    Edgar
    Sunday, November 3, 2019 3:37 AM
    Moderator
  • Hi Jordan,
    Can you send the network trace to dochelp at Microsoft dot com? 

    Regards,
    Sreekanth

    Monday, November 4, 2019 3:37 PM
    Moderator
  • Sure, is there a guide or steps I can follow to easily generate this trace?
    Monday, November 4, 2019 7:42 PM
  • Hi Jordan,
    It is the same wireshark trace you have captured. Can you send it by e-mail to dochelp at Microsoft dot com? 

    Regards,
    Sreekanth

    Monday, November 4, 2019 9:07 PM
    Moderator
  • Hi Sreekanth

    Thanks, I've sent an email with a capture for a working (non compound) scenario as well as the failure one. The capture is different from the screenshots above so the frames won't line up but the issue is still present.

    While I didn't attach a capture when encryption was enabled as you can not decrypt it the issue is still present. The Create and Change Notify request are sent as a compound message under the 1 SMB Transform Header but the server returns 2 headers back with the latter having the wrong Session Id so I cannot decrypt it.

    Thanks

    Jordan

    Tuesday, November 5, 2019 4:50 AM
  • We have worked through this through email and came to the conclusion that you can lookup the proper Session Id for verification using the Message Id of the response and find the corresponding request's value.

    As for the encryption side, this wasn't an actual issue on Microsoft's SMB implementation but I was seeing the behaviour on Samba only. I will file a bug there for that issue.

    • Marked as answer by jborean93 Wednesday, November 6, 2019 8:32 PM
    Wednesday, November 6, 2019 8:32 PM