Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Jun 2012 09:32:41 +0200
From: magnum <>
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).


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 []
>> 2012/6/25 Solar Designer<>:
>>> 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.