Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <455f4fed229ada8dcbe208c1c10524bb@smtp.hushmail.com>
Date: Tue, 26 Jun 2012 09:13:38 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Jumbo candidate vs Test Suite

On 2012-06-26 04:17, SAYANTAN DATTA wrote:
> On Mon, Jun 25, 2012 at 9:49 AM, jfoug<jfoug@....net>  wrote:
>
>> Could this be buffer overwrites, smashing passwords?  The TS was written
>> specifically to cause this form of corruption on formats which require
>> additional sanity checking, prior to copying passwords.
>>
>> If you look at the pw.dic file (and others???) there will be some bugus,
>> unused lines that are long.  These are on purpose, and they have flushed
>> out
>> overwrite issues in many of the jumbo formats.
>>
>> This often shows up, if you have a format, where there is an array of
>> candidates worked on at the same time, and these are interspersed (such as
>> SSE), and part of the input buffer is not written to, because it is not
>> supposed to ever be modified.  Then, if an overlong password is copied into
>> this buffer, and is longer than it should be, and overflows, then that
>> array
>> element (and possibly OTHERS), will never find a password again, for the
>> rest of the run.
>>
>> When magnum and I were working through a lot of the formats, and designing
>> the TS, we built it this way, and shook out a LOT of bugs.  What you are
>> listing for numbers IS in the range we were used to seeing (40 to 60%
>> found,
>> out of the 1500).
>>
>> The work around for this, was determining just WHAT the max number of bytes
>> that can be in a password for your format, and making damn sure that you
>> truncate any password input line longer than this, to that many bytes, so
>> as
>> to NEVER overflow your pristine buffers.
>>
>> I do not know if this is the issue, but from experience, it sounds like it
>> 'could' be.    IF this IS the case, then the TS is 100% valid, in flushing
>> the bug out, it IS a bug.  You will have users that use 'dirty' wordlists,
>> which contain some pretty long lines.  If you do not properly limit and
>> protect your format, these dirty input files WILL cause passwords to be
>> missed.
>>
>> Jim.
>>
>>> From: Lukas Odzioba [mailto:lukas.odzioba@...il.com]
>>>
>>> 2012/6/25 Solar Designer<solar@...nwall.com>:
>>>> Do you have an idea of what the remaining problem is?
>>>
>>> If I had to guess: UTF, Unicode, salt/pass length.
>>
>>
> Yeah, mscash2-opencl guessed 1410 times only after I reduced the plaintext
> length to 31 from 40 . I couldn't understand this at first but now it is
> clear.

Lukas is right. If the format supports max 27 characters, you must set 
your PLAINTEXT_LENGTH to 27. Maybe you need a PLAINTEXT_LENGTH of 27 but 
keep the buffer a multiple of 32 octets.

magnum

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.