Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Aug 2012 23:41:41 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Serious bug in -fixes and all other branches

On 2012-08-13 22:49, jfoug wrote:
> From: magnum
>> We have a serious loader problem. It often segfaults while reading
>> a pot file containing other formats than what we are loading. This
>> is in all branches, including -fixes :(
>> 
> For 'fixes' version, lets simply roll back these changes  to loader.
> The side effects, are that any found password of dynamic type, will
> not be removed from JtR on its next run, if the .pot line for that
> hash had a $HEX$ added.    But this will remove the other 'bad' side
> effects of this change.

I now rolled it back (*only* the ldr_load_pot_line() changes, nothing
else, even in loader.c) in all branches.

> This problem is more difficult than it appears, since the INPUT file
> may have $HEX$ values, and thus, within loader, those should not be
> undone.  I am at a quandary about this issue.  It may be that I have
> to modify the part of dynamic that makes the initial change, right
> before storing the .pot line, and not use $HEX$, but use some
> 'internal' value, that is only set prior to the .pot writing, and
> THEN if we detect that string, we undo it at split time.

I would think all this can be solved with prepare() - although maybe not
with exactly the same behavior as you had here. For instance, even if NT
reads a pwdump file, it stores hashes in the pot file in the canonical
way. When you --show same pwdump file, it works fine (but is not shown
in pwdump format). I would think a similar scheme could apply here, but
I understand there may be caveats.

> For the loader call, I probably need to ONLY perform the split logic,
> if the format is a FMT_DYNAMIC type, otherwise, simply revert to the
> original behavior, and return.  For dynamic, we will call split to
> 'possibly' chop back the hex.   The 'other' option, is to make valid
> more complex, and slower (it already is the slowest valid() function
> by far).

OTOH, loading speed is not helped by calling split() for every single
hash in a 3 GB pot file ;-)

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.