Re: [PATCH 2/2] ksmbd: add AES-GMAC signing support

[Ian Bridges]

Hi Michail,

With patch 2, an existing gap in SMB3 binding request verification
leads to AES-GMAC nonce reuse. It needs
"server multi channel support = yes", which is disabled by default.

In the multichannel branch of smb2_sess_setup(), ksmbd checks that
SMB2_FLAGS_SIGNED is present but does not verify the request with the
existing Session.SigningKey, as MS-SMB2 3.3.5.2.4 requires. The request
can then reach authentication processing, and a non-success
SESSION_SETUP response is signed with that session key.

I reproduced this with multichannel enabled and AES-GMAC negotiated.
Three new connections sent binding SESSION_SETUP requests for an
existing session, each with MessageId 1 and a random signature. All
three returned STATUS_MORE_PROCESSING_REQUIRED. Each response was
signed with the existing session's key and used the nonce
010000000000000001000000.

The responses contained different NTLM challenges, so distinct
messages were authenticated with the same AES-GMAC key and nonce.

This violates GMAC's nonce-uniqueness requirement (NIST SP 800-38D).
The same test with AES-CMAC confirms the pre-existing signing oracle,
but does not create the GMAC nonce-reuse problem.

The probe also recovers the GHASH key from four of these responses,
two pairs of different lengths, without the signing key. With the
GHASH key and one more response, it computes a tag for a different
message at MessageId 7 that verifies under the session's signing key.
A single connection reaches other MessageIds by stepping through the
credits the server grants, 64 per response.

Could the binding request be verified with Session.SigningKey before
it is processed or any response is signed with that key?

Thanks,
Ian