Date: Mon, 23 May 2011 23:47:30 -0500 From: "JFoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: Re: jumbo-1 SSE testing The 'same' bug that was in mssql05 was in mssql (only in builds MMX_COEF). However, since I did not have test vectors for mssql, I was not sure of this. It looked the same but I was not 100% sure. As for original MSSql, there are 2 salted SHA1 hashes stored within the same PW hash. They are very similar. We only compute one, and I am wondering if this is not enough, and we really are not 'cracking' the password. However, I do not know how MSSql uses it, so I am not 'sure'. What is stored is a salt (4 byte), and 2 SHA hashes. The hashes are: sha1(unicode(pass).salt).sha1(unicode(uppercase(pass)).salt) We compute the 2nd one, in john. Are we 'sure' we are getting the password (i.e. is sql server case insensitive?) Or is this like getting an NTLM from a pair of cracked LM keys. We have the letters, but have to brute the case. If SQL server is case sensative (the information appears to be there), then we should crack using upper case, then brute out the 'real' password. However, I am getting the mssql SSE patch updated with both formats. I am going to check over other SSE (32 bit) formats, and make sure none of them have this same bug. The bug is having a length value, that is only cleared out at load key time (usually only with index == 0), but then does += computations within crypt, and is a salted format. Crypt is called many times (once per each salt) for salted formats, prior to loading new keys. Thus, that MMX_COEF length number array needs to be preserved. I image there are not too many of these, since the test suite will flush them out pretty quickly. It would be in formats not yet in the test suite. Jim. ----- Original Message ----- From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Sent: Monday, May 23, 2011 1:11 PM Subject: RE: [john-dev] jumbo-1 SSE testing > Found the bug in mssql05. The format continued to += the 'total_len' > variable each new salt (same passwords). Thus, each loop through the > crypt_all for the next salt would add 4 bytes length to each crypt input. > The code did not add more bytes, but overwrote them properly. However, it > 'claimed' the length to grow 4 bytes each loop through. > > Thus, it was busted for anything over 1 salt at a time. > > Again, this brings back the case I made a few months back. That is that > john's self test only tests 1 salt, and not multi-salt senerios.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ