[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
