5.1 Security Considerations for Implementers
The protocol does not sign oplock break requests from the server to the client if message signing is enabled. This could allow attackers to affect performance but it does not allow them to deny access or alter data.
The protocol does not require cancel requests from the client to the server to be signed if message signing is enabled. This could allow attackers to cancel previously sent messages from the client to the server on the same SMB2 transport connection.
The previous versions support does potentially allow access to versions of a file that have been deleted or modified, and so could allow access to information that was not available without these extensions. However, this access is still subject to the same access checks it would have normally been subject to.
The SMB 2.0.2 and SMB 2.1 dialects do not support encryption. The SMB 3.x dialect family optionally allows for encryption. For data that requires stricter security, encryption by the SMB protocol version 3 is preferred. Alternatively, encryption of the data by the underlying transport is provided.
All SMB2 dialects use a session key returned by the authentication mechanism to generate keys for signing, encryption, and decryption. If the session keys are nonrandom or can be forced to be repeated in a predictable manner, attackers could deduce the signing and decryption keys and thereby gain access to messages and data.