Bug 14484 - Signature 8 bytes too late in SMB_COM_READ_ANDX response with vers=1.0
Summary: Signature 8 bytes too late in SMB_COM_READ_ANDX response with vers=1.0
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.12.5
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-08 21:09 UTC by наб
Modified: 2022-01-25 12:57 UTC (History)
1 user (show)

See Also:


Attachments
journal with signature field dumps (69.54 KB, text/plain)
2020-09-08 21:11 UTC, наб
no flags Details
journal with signature field dumps and command when they mismatch (43.52 KB, text/plain)
2020-09-08 21:12 UTC, наб
no flags Details
journal with signature field dumps and command (163.48 KB, text/plain)
2020-09-08 21:12 UTC, наб
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description наб 2020-09-08 21:09:26 UTC

    
Comment 1 наб 2020-09-08 21:10:15 UTC
When mounting a share with vers=1.0, Linux starts spewing
  CIFS VFS: SMB signature verification returned error = -13
in the console.

I've tracked this down to fs/cifs/cifsencrypt.c,
and ended up with the following test diff:
-- >8 --
diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index 9daa256f69d4..8a4b1230456c 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -249,14 +249,15 @@ int cifs_verify_signature(struct smb_rqst *rqst,
 	rc = cifs_calc_signature(rqst, server, what_we_think_sig_should_be);
 	mutex_unlock(&server->srv_mutex);

 	if (rc)
 		return rc;

-/*	cifs_dump_mem("what we think it should be: ",
-		      what_we_think_sig_should_be, 16); */
+	cifs_dump_mem("what we think it should be: ", what_we_think_sig_should_be, 16);
+	cifs_dump_mem("what we got               : ", server_response_sig, 16);
+	cifs_dbg(VFS, "command 0x%x\n", cifs_pdu->Command);

 	if (memcmp(server_response_sig, what_we_think_sig_should_be, 8))
 		return -EACCES;
 	else
 		return 0;

-- >8 --

Which gave me a lot of commands for which these match,
and one for which it never does:
  00000000: 64f2afd0 dde0c5bb 75ef0a94 80709bd2  ...d.......u..p.
  00000000: 7e2b6743 d6e41c45 64f2afd0 dde0c5bb  Cg+~E......d....
  CIFS VFS: command 0x2e
  CIFS VFS: SMB signature verification returned error = -13
  00000000: c98b9132 30252349 39449157 ffc57562  2...I#%0W.D9bu..
  00000000: 3438112b cb8cbaff c98b9132 30252349  +.84....2...I#%0
  CIFS VFS: command 0x2e
  CIFS VFS: SMB signature verification returned error = -13
  00000000: acf8acda 8fc2b185 6721020b 8f572a61  ..........!ga*W.
  00000000: a38ab6b3 abb39b3d acf8acda 8fc2b185  ....=...........
  CIFS VFS: command 0x2e
  CIFS VFS: SMB signature verification returned error = -13
More logs attached (+dump doesn't log command, +cmd only on error,
 +all is as above; suboptimal, I know, but it's what I've got).

Note how the signatures match what Linux expected,
but are offset by 8 bytes in each case.

[MS-CIFS] seems to indicate that 0x2e is SMB_COM_READ_ANDX,
hence the subject.

Tracing the calls, it looks as if the header generation for this command
always ends up in setup_readX_header() in source3/smbd/reply.c,
but I know bugger-all about the Samba code-base or the protocol
in general, so I may be barking up the wrong tree entirely.
Comment 2 наб 2020-09-08 21:11:45 UTC
Created attachment 16203 [details]
journal with signature field dumps
Comment 3 наб 2020-09-08 21:12:08 UTC
Created attachment 16204 [details]
journal with signature field dumps and command when they mismatch
Comment 4 наб 2020-09-08 21:12:23 UTC
Created attachment 16205 [details]
journal with signature field dumps and command