Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 May 2011 08:10:26 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: SSE bug still there in Jumbo-5-RC6++

The patch was due to the password length being 32 bytes, and the 0x80 being 
stored in the buffer also.  It will only show up if cracking a 32 byte 
password (there are non in the test suite, yet.   If we go back to 32 byte 
memcpy, then we should set max password length to 31 bytes (so the 0x80 
'fits') in the dword contained in the first 32.

One thing that should be added to the test suite input files is another 20 
candidates (sprinkled through the file), that are the MAX size of the 
password allowed for the format (removing 20 other's or simply going to 
1340).  Also, we need to add some words to pw.dic that are LONG passwords, 
longer than any format can handle, and again spread throughout the file. 
Those longer PW'd will hopefully smoke out overwrite issues.  The one where 
we have the most likelyhood of overwrites is in md5-gen, since there is no 
easy way to set a max sized input password.

Jim.

----- Original Message ----- 
From: "magnum" <rawsmooth@...dband.net>
To: <john-dev@...ts.openwall.com>
Sent: Thursday, May 26, 2011 5:37 AM
Subject: Re: [john-dev] SSE bug still there in Jumbo-5-RC6++


> Erik, Jim,
>
> Please try the attached rawMD5unicode_fmt.c
>
> It solves ALL problems for me on x86-64, x86-sse2 and x86-mmx and the
> OpenLDAPS can be enabled again. Everything passes self tests and test
> suite. It also speed things up as I dropped saved_plain completely and
> rebuild it from the key buffer instead.
>
> However, I must also revert the following hunk in Jim's latest SSE2
> patch in order to get NSLDAP going:
>
> --- john-1.7.7-jumbo-5-RC6/src/NSLDAP_fmt.c 2011-05-23
> 18:51:00.000000000 +0000
> +++ john-1.7.7-jumbo-5/src/NSLDAP_fmt.c 2011-05-24 05:20:43.625000000 
> +0000
> @@ -225,7 +225,8 @@ static int cmp_one(void * binary, int in
>  static void
>  crypt_all(int count) {
>  #ifdef MMX_COEF
> - memcpy(buffer, saved_key, 32*MMX_COEF);
> + // 32 byte password (max), plus the 0x80.  We need to copy 36*MMXCOEF
> to make sure we get it all.
> + memcpy(buffer, saved_key, 36*MMX_COEF);
>  shammx((unsigned char *) crypt_key, buffer, total_len);
>  #else
>    static SHA_CTX ctx;
>
>
> Jim, was that really a correct patch? I get 1320 found on all platforms
> without that and self test fail with it.
>
> magnum
>
>
> On 2011-05-26 05:45, JFoug wrote:
>> I get a crash on OpenLDAPS. Same type. Only MMX/SSE builds (from
>> cygwin/mingw). It also only crashes on -test not on -test
>> -format=openssha The format_init has been commented out in john.c for a
>> couple of releases, but this is the same type of bug, and really needs
>> to be found.
>>
>> Jim.
>>
>> ----- Original Message ----- From: "Erik Winkler" <ewinkler@...ls.com>
>> To: <john-dev@...ts.openwall.com>
>> Sent: Wednesday, May 25, 2011 10:00 AM
>> Subject: Re: [john-dev] SSE bug still there in Jumbo-5-RC6++
>>
>>
>> Jumbo-5-RC6++ works great on MacOS X for 64-bit build. No issues.
>>
>> On MacOS X using the sse2 build, I get the following error for NSLDAP
>> benchmarking:
>>
>> Benchmarking: Netscape LDAP SHA SSE2 [SHA-1]... FAILED (get_hash[0](3))
>>
>> Now this only occurs when running ./john -test. If I run ./john -test
>> -format:nsldap, it works correctly:
>>
>> ../run/john -test -format:nsldap
>> Benchmarking: Netscape LDAP SHA SSE2 [SHA-1]... DONE
>> Raw: 7837K c/s real, 7837K c/s virtual
>>
>> Not sure why.
>>
>> Erik
>>
>> On May 24, 2011, at 1:58 PM, magnum wrote:
>>
>>> Even after applying all incremental patches posted to the wiki, there
>>> are some problems left in Jumbo-5-RC6:
>>>
>>> 1. Raw-MD4 segfaults for me on linux-x86-sse2:
>>> * Using linux-x86-mmx I saw no problem.
>>> * It segfaults when running "--test"
>>> * It does NOT segfault when running eg. "--test --fo:raw-MD4"
>>> * Test suit does NOT segfault and all 1320 is found
>>>
>>> This led me to believe the problem was in the format running right
>>> before raw-MD4 on a --test run, namely salted-sha1. I did find a bug
>>> in that format (fix included in patch just posted) but that was not
>>> the cause of this.
>>>
>>> 2. NSLDAP has a problem on linux-x86-sse2 and linux-x86-mmx:
>>> Benchmarking: Netscape LDAP SHA MMX [SHA-1]... FAILED (get_hash[0](1))
>>>
>>> I have no time to investigate further right now.
>>>
>>> magnum
>>
>
> 

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ