Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 12 Jul 2015 17:18:03 +0300
From: Solar Designer <>
Subject: Re: more robustness

Hi Kai,

On Sun, Jul 12, 2015 at 07:46:48PM +0800, Kai Zhao wrote:
> To mimic the real cracking process, I tried to change the loader.c to reuse
> for fuzzing. The last three commits reuse loader.c for fuzzing.

I'm not happy that you're making any changes to loader.c at all, but the
changes are relatively small, so this may be acceptable.

magnum - please take a look, I think these changes are more in your area.

[ fuzz_option]$ git diff cc6012eaf61c67800da7ef33b44fa7f19fa5d631 | diffstat 
 run/fuzz.dic       |   76 ++++++
 run/ |  155 +++++++++++++
 src/    |    4 
 src/fuzz.c         |  594 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/fuzz.h         |   11 
 src/john.c         |    6 
 src/loader.c       |   52 ++++
 src/loader.h       |    5 
 src/options.c      |    8 
 src/options.h      |   15 +
 10 files changed, 920 insertions(+), 6 deletions(-)

> After reuse loader.c::ldr_load_pw_line(), --fuzz now fuzz those functions:
> prepare(), valid(), init(), split(), binary(), salt(), salt_hash().
> However, there
> are some functions in crack.c before crypt_all(), such as set_salt(),
> clear_keys(), set_key(). **Should I fuzz these functions ? **

Since in some formats we're effectively starting the hashing in
set_salt() or/and set_key(), I think it'd only be consistent to fuzz
those if we also proceeded with crypt_all().

So for now the answer is no.

> There are 4 bugs found by the latest --fuzz.
> Bugs are below:

OK, although this brings up the question: why were not these found by
fuzzing earlier, prior to --fuzz option?

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.



Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ