[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 10:01:36 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: auditing our use of FMT_* flags (was: more robustness)
> On Sun, Jul 26, 2015 at 2:57 AM, Solar Designer
> <solar@...nwall.com> wrote:
>
> Kai,
>
> On Sun, Jul 12, 2015 at 05:18:03PM +0300, Solar Designer wrote:
> > Unrelated, here's a task for you for next week: identify improperly set
> > or missing FMT_* flags. For example, a format supporting 8-bit chars in
> > passwords (unlike descrypt, which drops the 8th bit, by its definition),
> > but forgetting to set FMT_8_BIT. Or vice versa. Ditto about FMT_CASE,
> > FMT_OMP, etc. One of the trickier flags is FMT_SPLIT_UNIFIES_CASE, and
> > even trickier is split() actually needing to do this in some cases.
> > Maybe magnum will help you figure these out. (My availability will
> > likely be too limited, unfortunately.)
> >
> > Maybe you can even write a script that would spot some of the likely
> > improper flag (non-)uses. e.g. a _fmt*.c file mentions OpenMP stuff,
> > but never mentions FMT_OMP, or vice versa. Some of this could be easier
> > detected at runtime - e.g., "\x20" and "\xa0" hashing differently, but a
> > format lacks FMT_8_BIT, or vice versa. Your builtin fuzzer or extended
> > self-test could detect that.
>
> What's the status on this sub-project?
>
> I expected you'd find lots of bugs of this sort.
Sorry, I have not found bugs on FMT_ flags.
I have written a script to check, and change john source code to check
FMT_SPLIT_UNIFIES_CASE. They are described at:
http://www.openwall.com/lists/john-dev/2015/07/21/6
I thought there were some problems but they were not.
Thanks,
Kai
Content of type "text/html" skipped
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.
