[BUG] ksmbd: no check that transform SessionId matches inner one on encrypted requests

[Dairui Zhang <zhangdairui@gmail.com>]

Hi,

I can't find any place where ksmbd checks that the SessionId in the
encryption transform header matches the SessionId in the decrypted
SMB2 header, and the two are used for different things:

  - the decryption key is selected by the transform SessionId:
    ksmbd_crypt_message() -> ksmbd_get_encryption_key(work,
    le64_to_cpu(tr_hdr->SessionId), ...) (auth.c:849)
  - the session that authorizes the request is selected by the
    decrypted inner header: smb2_check_user_session() ->
    ksmbd_session_lookup_all_states(conn,
    le64_to_cpu(req_hdr->SessionId)) (smb2pdu.c:938)

The only reader of tr_hdr->SessionId in the server directory is the
key lookup itself. And since encrypted requests are exempt from the
signing requirement (server.c:144), a valid AEAD tag is the only
proof of session identity - but it is checked against the wrong
session.

So on a connection carrying more than one session, a client can send
a request whose transform header names session A (decrypts with A's
key) while the inner header names session B. The command executes
with B's identity, tree connects and handles. The response is
encrypted with B's key (or sent plaintext if B's session has no enc
flag), so the sender learns nothing from it - but the write has
already happened as B.

The case I have in mind is a cifs multiuser mount, where one TCP
connection legitimately carries sessions of several users: a local
user with their own session key could act as another user on the same
connection. Session ids are allocated sequentially from 1
(ksmbd_ida.c:18), so they look enumerable. On a one-session-per-
connection setup I don't think this gains an attacker anything -
please correct me if I'm wrong.

As I read MS-SMB2, the server is supposed to verify the two
SessionIds match and treat a mismatch as a protocol error.

Suggested fix: compare the transform SessionId with the inner one
after decryption and drop the connection on mismatch. Happy to send
a patch if that approach sounds right.

This is my first report to this list, and it's from code reading
only - if I've misread the flow somewhere, please tell me.

Thanks,
Dairui Zhang