Here is the note where I am suspecting Samba rc4 encryption code may have a bug... ------------------------------- With a master key/ session key hardcoded as 0x0102030405060708090a0b0c0d0e0f00 and a payload hardcoded as jCIFS, I think Samba server may be generating incorrect SSPI signature. With cifs client, this is the SSPI signature [0000] 01 00 00 00 E3 7F 97 F2 54 4F 4D 7E 00 00 00 00 and Samba server genereates this as SSPI signature [0000] 01 00 00 00 3F 38 D2 E3 5A 37 1F F3 00 00 00 00 I picked these hardcoded values from Davenport document and the NTLM2 SSPI signature generated by cifs client matches with the SSPI signature generated in that example. cifs client and Samba server agree till hmac-md5 hash generated during SSPI signature calculation 0236000a 9a757a31 and 0A 00 36 02 31 7A 75 9A but differ when encrypting this using client sealing key f2977fe3 7e4d4f54 and 3F 38 D2 E3 5A 37 1F F3 cifs client uses kernel crypto apis for rc4 encryption and Samba server uses function arcfour_crypt_sbox(). I verified that the client/receive sign and seal keys are the same. recv sign key: dump of 16 bytes of data at 0xffff8801366b8960 827af9f7 9c0f39ec 4fac3d90 32b1ce6a ÷ ù z . ì 9 . . . = ¬ O j Î ± 2 recv seal key: dump of 16 bytes of data at 0xffff8801366b8e68 95f58527 283e3f29 739d4313 0d8123a2 ' . õ . ) ? > ( . C . s ¢ # . . [0000] F7 F9 7A 82 EC 39 0F 9C 90 3D AC 4F 6A CE B1 32 ..z..9.. .=.Oj..2 NTLMSSP Sign/Seal - RECV SEAL KEY [0000] 27 85 F5 95 29 3F 3E 28 13 43 9D 73 A2 23 81 0D '...)?>( .C.s.# session key is not weakened to generate sealing keys. Both cifs client and Samba server agree on these flags NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_SIGN NTLMSSP_NEGOTIATE_SEAL NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH NTLMSSP_NEGOTIATE_56 hmac-md5 hash values match between cifs client and Samba sever but rc4 encryption values of this hmac-md5 hash differ. I do not think client sealing keys used in encryption are different. /usr/local/samba/sbin/smbd -V Version 3.6.0-GIT-UNKNOWN-devel
Ok Shirish, can you be very specific as to the keys/payload you're testing ? e.g. Let's do this as a test vector, so we have: key=0xHEX_VALUE data=0xHEX_VALUE then specify the exact steps being used. If you're referring a specific example in the Davenport document then please link to it and explain what values and steps are being done. I can then try and reproduce, and investigate if there's an issue here. Thanks ! Jeremy.
Created attachment 7408 [details] cifs client sspi signature generation code (with fixed constants) cifs client code that generates sspi signature
Hi Jeremy, I am referring Davenport document http://davenport.sourceforge.net/ntlm.html and section NTLM2 Session Security key = 0x0102030405060708090a0b0c0d0e0f00 data = "jCIFS" I just attached the cifs code that generates sspi signature. Will document later today various keys and constants with above two values. With above, I am expecting a sspi signature of 0x01000000e37f97f2544f4d7e00000000 as per the Davenport document.
Here are the values: session key: dump of 16 bytes of data at 0xffff880136791700 04030201 08070605 0c0b0a09 000f0e0d . . . . . . . . . . . . . . . . client/recv sign key: dump of 16 bytes of data at 0xffff8801366b8ae8 827af9f7 9c0f39ec 4fac3d90 32b1ce6a ÷ ù z . ì 9 . . . = ¬ O j Î ± 2 client/recv seal key: dump of 16 bytes of data at 0xffff8801366b8ea0 95f58527 283e3f29 739d4313 0d8123a2 ' . õ . ) ? > ( . C . s ¢ # . . unsealed payload: dump of 13 bytes of data at 0xffff88010ab98180 09000000 424d53ff 4649436a c0050053 . . . . ÿ S M B j C I F S hmac-md5 hash: dump of 16 bytes of data at 0xffff880106b2da58 0236000a 9a757a31 c7c90d72 5752a9a2 . . 6 . 1 z u . r . É Ç ¢ © R W unsealed 8 byte signature: dump of 8 bytes of data at 0xffff880106b2da58 0236000a 9a757a31 . . 6 . 1 z u . sealed 8 byte signature: dump of 8 bytes of data at 0xffff880106b2da58 f2977fe3 7e4d4f54 ã . . ò T O M ~ sspi signature: dump of 16 bytes of data at 0xffff880106b2da68 00000001 f2977fe3 7e4d4f54 00000000 . . . . ã . . ò T O M ~ . . . . sealed payload: dump of 13 bytes of data at 0xffff88010ab98180 09000000 424d53ff 4649436a c0050053 . . . . ÿ S M B j C I F S complete payload: dump of 29 bytes of data at 0xffff88010ab98180 19000000 000045ff 00000001 f2977fe3 . . . . ÿ E . . . . . . ã . . ò 7e4d4f54 00000000 b6e83c83 494b0036 T O M ~ . . . . . < è ¶ 6 The Davenport document, has sspi signature as 0x01000000e37f97f2544f4d7e00000000 which is what cifs client comes up with. Samba generates this error BAD SIG NTLM2: wanted signature of [0000] 01 00 00 00 3F 38 D2 E3 5A 37 1F F3 00 00 00 00 ....?8.. Z7...... [2012/03/27 12:09:54.323530, 5] libsmb/ntlmssp_sign.c:227(ntlmssp_check_packet) BAD SIG: got signature of [0000] 01 00 00 00 E3 7F 97 F2 54 4F 4D 7E 00 00 00 00 ........ TOM~.... 8 byte digest matches, [0000] 0A 00 36 02 31 7A 75 9A the rc4 encryption of this digest is different. [0000] 3F 38 D2 E3 5A 37 1F F3 hence the sspi signature
Since Samba server is generating same (unsealed) signature as cifs client, I am thinking the contents that go into generating hmac-md5 hash are the same (i.e. sequence number and payload/message). It is rc4 encryption value is different when first 8 bytes of this hamc-md5 are same. That is why I am thinking either there is a bug in Samba rc4 encryption code or Samba is using different receive/client sealing key but since session key is not unweakened, I doubt Samba is using different receive/client sealing key.
Jeremy, is there any additional info that needs to be furnished? One observation is, during ntlmssp session setup, the nonce is encrypted using rc4. That encryption seems to match between Samba server and cifs client since ntlmssp session setup completes successfully. So why would rc4 encrypted values of the same first 8 bytes of the 16 byte hmac-md5 hash using the same receive/client sealing key be different!
OK, I know the problem. Not a bug in Samba code, bug in cifs code. cifs client was setting the client/receive_side sealing key twice, first to genereate sealed payload and then to generate seal sspi signature. Instead, what cifs client now is doing is generate hmac-md5 hash, set the rc4 cipher sealing key, encrypt payload and without resetting the rc4 cipher sealing key again, encrypt the sspi hmac-md5 hash. With that sspi signatures match. XXX wanted signature of [0000] 01 00 00 00 3F 38 D2 E3 5A 37 1F F3 00 00 00 00 ....?8.. Z7...... [2012/04/01 05:36:42.632376, 5] libsmb/ntlmssp_sign.c:219(ntlmssp_check_packet) XXX: got signature of [0000] 01 00 00 00 3F 38 D2 E3 5A 37 1F F3 00 00 00 00 ....?8.. Z7...... [2012/04/01 05:36:42.632506, 10] libsmb/ntlmssp_sign.c:249(ntlmssp_check_packet) ntlmssp_check_packet: NTLMSSP signature OK ! I need to clean-up cifs client code with this change, then handle the receive side in cifs client. This bug can be closed.
Close per submitter comment