Bug 8828 - possible rc4 encryption error in Samba libraries
Summary: possible rc4 encryption error in Samba libraries
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.6.0rc1
Hardware: All All
: P5 major
Target Milestone: ---
Assignee: Volker Lendecke
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 03:08 UTC by shirishpargaonkar@gmail.com
Modified: 2012-04-01 23:11 UTC (History)
1 user (show)

See Also:


Attachments
cifs client sspi signature generation code (with fixed constants) (7.67 KB, text/plain)
2012-03-27 19:58 UTC, shirishpargaonkar@gmail.com
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description shirishpargaonkar@gmail.com 2012-03-27 03:08:13 UTC
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
Comment 1 Jeremy Allison 2012-03-27 18:26:00 UTC
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.
Comment 2 shirishpargaonkar@gmail.com 2012-03-27 19:58:27 UTC
Created attachment 7408 [details]
cifs client sspi signature generation code (with fixed constants)

cifs client code that generates sspi signature
Comment 3 shirishpargaonkar@gmail.com 2012-03-27 20:02:49 UTC
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.
Comment 4 shirishpargaonkar@gmail.com 2012-03-28 04:58:30 UTC
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
Comment 5 shirishpargaonkar@gmail.com 2012-03-28 13:15:46 UTC
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.
Comment 6 shirishpargaonkar@gmail.com 2012-03-30 15:00:17 UTC
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!
Comment 7 shirishpargaonkar@gmail.com 2012-04-01 22:23:45 UTC
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.
Comment 8 Steve French 2012-04-01 23:11:53 UTC
Close per submitter comment