Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 May 2011 23:47:30 -0500
From: "JFoug" <>
To: <>
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.


----- Original Message ----- 
From: "jfoug" <>
To: <>
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.