[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e696da9e159a80ad67b8342f0140c186@smtp.hushmail.com>
Date: Mon, 25 Jun 2012 09:32:41 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Jumbo candidate vs Test Suite
This is a very good suggestion. While we normally always get truncated
candidates nowadays (in Jumbo), the SALTS may well be longer than what
you handle. For mscash formats, this *is* the case in TS. Like Jim says
it is on purpose.
Easy fix is to reject those hashes in valid(). Look at
mscash1_fmt_plug.c for how to do that (tricky unicode business).
magnum
On 2012-06-25 06:19, jfoug 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.
>
>
>
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.
