From: Ian Bridges <icb@fastmail.org>
To: mike.michalo@gmail.com
Cc: linkinjeon@kernel.org, senozhatsky@chromium.org, tom@talpey.com,
chenxiaosong@chenxiaosong.com, ematsumiya@suse.de,
linux-cifs@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Ian Bridges <icb@fastmail.org>
Subject: Re: [PATCH 2/2] ksmbd: add AES-GMAC signing support
Date: Tue, 3 Nov 2026 11:17:42 -0600 [thread overview]
Message-ID: <20261103171742.18816-1-icb@fastmail.org> (raw)
In-Reply-To: <20261103111453.84804-3-mike.michalo@gmail.com>
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
next prev parent reply other threads:[~2026-11-03 17:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 11:14 [PATCH 0/2] ksmbd: " Michail Andreas Michalopoulos
2026-11-03 11:14 ` [PATCH 1/2] ksmbd: sign with the negotiated SMB 3.1.1 signing algorithm Michail Andreas Michalopoulos
2026-11-03 11:14 ` [PATCH 2/2] ksmbd: add AES-GMAC signing support Michail Andreas Michalopoulos
2026-11-03 17:17 ` Ian Bridges [this message]
2026-11-03 17:57 ` mixalhs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261103171742.18816-1-icb@fastmail.org \
--to=icb@fastmail.org \
--cc=chenxiaosong@chenxiaosong.com \
--cc=ematsumiya@suse.de \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.michalo@gmail.com \
--cc=senozhatsky@chromium.org \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®