[PATCH linux-next] cifs: Cleanup and clarify CalcNTLMv2_response()

[Tim Gardner]

Use of a structure aids in the understanding of this
seemingly simple bit of code. The addition of a couple
of comments also helps.

Cc: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+***@public.gmane.org>
Cc: Steve French <sfrench-***@public.gmane.org>
Signed-off-by: Tim Gardner <timg-***@public.gmane.org>
---

I'd just like to be sure that the destructive copy is
really what was intended. I can't tell from reading the MSDN
section 3.3.2 NTLM v2 Authentication. It sort of makes
my head hurt.

rtg

fs/cifs/cifsencrypt.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index fc6f4f3..fecbfd0 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -548,7 +548,9 @@ static int
CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
{
int rc;
- unsigned int offset = CIFS_SESS_KEY_SIZE + 8;
+ struct ntlmv2_resp *resp = (struct ntlmv2_resp *)
+ (ses->auth_key.response + CIFS_SESS_KEY_SIZE);
+ unsigned int hashed_len = ses->auth_key.len - (CIFS_SESS_KEY_SIZE + 8);

if (!ses->server->secmech.sdeschmacmd5) {
cifs_dbg(VFS, "%s: can't generate ntlmv2 hash\n", __func__);
@@ -569,21 +571,30 @@ CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
return rc;
}

+ /*
+ * The cryptkey is part of the buffer that feeds the MD5 hash, but
+ * gets over written later by the digest. See crypto_shash_final()
+ * below.
+ */
if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED)
- memcpy(ses->auth_key.response + offset,
+ memcpy(&resp->ntlmv2_hash[CIFS_SERVER_CHALLENGE_SIZE],
ses->ntlmssp->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
else
- memcpy(ses->auth_key.response + offset,
+ memcpy(&resp->ntlmv2_hash[CIFS_SERVER_CHALLENGE_SIZE],
ses->server->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
- ses->auth_key.response + offset, ses->auth_key.len - offset);
+ &resp->ntlmv2_hash[8], hashed_len);
if (rc) {
cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
return rc;
}

+ /*
+ * Yes - this is destructive. The 16 byte MD5 digest clobbers the
+ * cryptkey that was just copied into &resp->ntlmv2_hash[8].
+ */
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
- ses->auth_key.response + CIFS_SESS_KEY_SIZE);
+ resp->ntlmv2_hash);
if (rc)
cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);

[Shirish Pargaonkar]

Tim,

Since when a NTLMv2 response is sent, contains a
session key, hmac-md5 digest, and the blob,
the offset has + 8 to include 16 bytes of hmac-md5 digest.
hmac-md5 digest is based on 8 bytes of server challenge
and the blob.
So hmac-md5 digest (output) overwrites total 16 bytes in overall
ntlmv2 response after session key and is followed by the blob.

At this point in time, we are dealing with the opaque data, so casting those
16 bytes (after session key and before the blob) as ntlmv2_response
structure does not appear correct and can be confusing.

Regards,

Shirish

Post by Tim Gardner
Use of a structure aids in the understanding of this
seemingly simple bit of code. The addition of a couple
of comments also helps.
---
I'd just like to be sure that the destructive copy is
really what was intended. I can't tell from reading the MSDN
section 3.3.2 NTLM v2 Authentication. It sort of makes
my head hurt.
rtg
fs/cifs/cifsencrypt.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index fc6f4f3..fecbfd0 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -548,7 +548,9 @@ static int
CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
{
int rc;
- unsigned int offset = CIFS_SESS_KEY_SIZE + 8;
+ struct ntlmv2_resp *resp = (struct ntlmv2_resp *)
+ (ses->auth_key.response + CIFS_SESS_KEY_SIZE);
+ unsigned int hashed_len = ses->auth_key.len - (CIFS_SESS_KEY_SIZE + 8);
if (!ses->server->secmech.sdeschmacmd5) {
cifs_dbg(VFS, "%s: can't generate ntlmv2 hash\n", __func__);
@@ -569,21 +571,30 @@ CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
return rc;
}
+ /*
+ * The cryptkey is part of the buffer that feeds the MD5 hash, but
+ * gets over written later by the digest. See crypto_shash_final()
+ * below.
+ */
if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED)
- memcpy(ses->auth_key.response + offset,
+ memcpy(&resp->ntlmv2_hash[CIFS_SERVER_CHALLENGE_SIZE],
ses->ntlmssp->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
else
- memcpy(ses->auth_key.response + offset,
+ memcpy(&resp->ntlmv2_hash[CIFS_SERVER_CHALLENGE_SIZE],
ses->server->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
- ses->auth_key.response + offset, ses->auth_key.len - offset);
+ &resp->ntlmv2_hash[8], hashed_len);
if (rc) {
cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
return rc;
}
+ /*
+ * Yes - this is destructive. The 16 byte MD5 digest clobbers the
+ * cryptkey that was just copied into &resp->ntlmv2_hash[8].
+ */
rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
- ses->auth_key.response + CIFS_SESS_KEY_SIZE);
+ resp->ntlmv2_hash);
if (rc)
cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
More majordomo info at http://vger.kernel.org/majordomo-info.html