Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Exception: STATUS_NOT_SUPPORTED: 0xc00000bb #72

Closed
glpub opened this issue Jan 26, 2021 · 4 comments · Fixed by #73
Closed

Exception: STATUS_NOT_SUPPORTED: 0xc00000bb #72

glpub opened this issue Jan 26, 2021 · 4 comments · Fixed by #73

Comments

@glpub
Copy link

glpub commented Jan 26, 2021

What can be the reason?

If I set dialect (2.0.2 or 2.1.0) in the connection, open session and connect a tree
tree.connect()
it works
without setting dialect it throws the same exception both in low-level and high-level APIs:

INFO:smbprotocol.tree:Session: user, Tree: \\my_server\common - Receiving secure negotiation response
Traceback (most recent call last):
  File "C:/Users/user/prj/research/python/sandbox/misc/smb_tester.py", line 41, in <module>
    for filename in listdir(r"\\my_server\common\DataScienceIn"):
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbclient\_os.py", line 232, in listdir
    with SMBDirectoryIO(path, mode='r', share_access='r', **kwargs) as dir_fd:
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbclient\_io.py", line 291, in __init__
    tree, fd_path = get_smb_tree(path, **kwargs)
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbclient\_pool.py", line 299, in get_smb_tree
    tree.connect()
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbprotocol\tree.py", line 271, in connect
    self._verify_dialect_negotiate()
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbprotocol\tree.py", line 329, in _verify_dialect_negotiate
    response = self.session.connection.receive(request)
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbprotocol\connection.py", line 617, in wrapped
    return func(self, *args, **kwargs)
  File "C:\Users\user\prj\research\python\sandbox\.venv-win\lib\site-packages\smbprotocol\connection.py", line 929, in receive
    raise SMBResponseException(response)
smbprotocol.exceptions.NotSupported: Received unexpected status from the server: The request is not supported. (3221225659) STATUS_NOT_SUPPORTED: 0xc00000bb
INFO:smbprotocol.tree:Session: user, Tree: \\my_server\common - Disconnecting from Tree Connect
INFO:smbprotocol.tree:Session: user, Tree: \\my_server\common - Sending Tree Disconnect message
@jborean93
Copy link
Owner

When we receive the tree connection response from the server we are meant to validate the negotiated connection dialects to ensure the server didn't downgrade as per https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5b80eb31-7e0a-4f24-b570-15217d28f239

If Connection.Dialect is not "3.1.1", MaxDialect belongs to the SMB 3.x dialect family, 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. The client MUST issue an SMB2 IOCTL Request as follows:

The error you are seeing is the server responding with STATUS_NOT_SUPPORTED when we send the VALIDATE_NEGOTIATE_INFO request so the client is not able to validate the negotiation. After reading that snippet I think the logic in smbprotocol is slightly wrong and that's why setting the lower dialects works in your case.

Currently we skip this validation if the negotiated dialect is not 3.0 or 3.0.2 and by setting the explicit dialect to 2.0.2 or 2.1.0 you are skipping that step. In reality based on the logic in the MS-SMB2 docs we should always be sending the validation as the MaxDialect is 3.1.1+ unless the negotiated dialect is 3.1.1 already.

In saying all that it doesn't help your problem where the server doesn't seem to support this type of message. If you are using the low level API you can specify tree.connect(require_secure_negotiate=False) to disable that validation, although be aware it will open you up to downgrade attacks. The high level API doesn't have any way to specify this logic but I can see adding require_secure_negotiate with a default of True to the ClientConfig which controls this behaviour.

I'm curious, what is the server you are connecting to, is it Samba, if so what version?

@glpub
Copy link
Author

glpub commented Jan 27, 2021

I'm curious, what is the server you are connecting to, is it Samba, if so what version?

I don't know actually, it is company's one. Windows have no problem to connect to it but almost any 3'd party client/library has (including linux smb client) the exception regarding STATUS_NOT_SUPPORTED.

@jborean93
Copy link
Owner

Thanks for the info, I believe #73 should solve your problem. It will ignore STATUS_NOT_SUPPORTED as along as the response was signed by the server as per Microsoft's recommendations in https://docs.microsoft.com/en-us/archive/blogs/openspecification/smb3-secure-dialect-negotiation

Down-level servers (pre-Windows 2012) will return STATUS_NOT_SUPPORTED or STATUS_INVALID_DEVICE_REQUEST since they do not allow or implement FSCTL_VALIDATE_NEGOTIATE_INFO. The client should accept the response provided it’s properly signed.

This will ignore the current STATUS_NOT_SUPPORTED error you are receiving bad, as long as the server had signed it. If the server has not signed it then you need to disable secure negotiation with smbclient.ClientConfig(require_secure_negotiate=False) which is a new option added in that PR.

@jborean93
Copy link
Owner

Version 1.4.0 has been released on PyPI which includes this fix https://pypi.org/project/smbprotocol/1.4.0/.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants