Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Jun 2015 05:56:51 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Fuzzing Report on hashes

On 2015-06-07 17:32, Kai Zhao wrote:
> 2. afl
> ------
>
> The fuzzing steps have been described here:
>
> http://www.openwall.com/lists/john-dev/2015/04/24/4
>
> There are 20 bugs found by afl. I have submitted them to jumbo.
>
> https://github.com/magnumripper/JohnTheRipper/issues/1392
> to
> https://github.com/magnumripper/JohnTheRipper/issues/1412
>
> The fuzzing status(without asan):
> --------------------------------------------
>
> start_time     : 1433337933
> last_update    : 1433687305
> fuzzer_pid     : 111919
> cycles_done    : 0
> execs_done     : 38789459
> execs_per_sec  : 123.56

Why the speed is so low? Due to the choice of hashes to start with or 
there are other reasons? Which hashes did you start with?

> paths_total    : 4286
> paths_found    : 4069
> paths_imported : 0
> max_depth      : 2
> cur_path       : 109
> pending_favs   : 712
> pending_total  : 4204
> variable_paths : 869
> bitmap_cvg     : 17.32%
> unique_crashes : 102
> unique_hangs   : 23
> last_path      : 1433683697
> last_crash     : 1433660850
> last_hang      : 1433672968
> exec_timeout   : 200
> afl_banner     : john
> afl_version    : 1.79b
> command_line   : afl-fuzz -m none -i input_cases/ -o out/ ../../john @@
> --nolog --skip-self-test

There is no --format option in this command line. I don't see much sense 
in fuzzing without fixing a format but I'm not sure how much it can slow 
things down. Fuzzing distinct formats separately gives you an 
opportunity to parallelize the process easily.

BTW have you tried to parallelize fuzzing with afl as described in 
parallel_fuzzing.txt?

> The fuzzing status(with asan):
> ----------------------------------------
>
> start_time     : 1433337926
> last_update    : 1433687375
> fuzzer_pid     : 106085
> cycles_done    : 0
> execs_done     : 11190917
> execs_per_sec  : 7.72

Do you know why it's so slow?

Anyway I don't think we should fuzz with asan unless we get a hint that 
it's worth it. One of nice things about afl is that it generates a good 
corpus of samples. Hence, generate a corpus without asan, then run it 
with asan and/or under valgrind.

And we should save the generated corpus.

> paths_total    : 2899
> paths_found    : 2682
> paths_imported : 0
> max_depth      : 2
> cur_path       : 61
> pending_favs   : 525
> pending_total  : 2857
> variable_paths : 1385
> bitmap_cvg     : 16.63%
> unique_crashes : 191
> unique_hangs   : 73
> last_path      : 1433647185
> last_crash     : 1433643332
> last_hang      : 1433674292
> exec_timeout   : 240
> afl_banner     : john
> afl_version    : 1.79b
> command_line   : afl-fuzz -m none -i input_cases/ -o out/ ../../john @@
> --nolog --skip-self-test
>
> 3. conclusion
> -----------------
>
> The afl takes about 4 days to find these bugs. Compared to the fuzz.pl
> script, afl is not that efficient but it can find different bugs. I think we
> should make full use of both afl and fuzz.pl.

AIUI afl should easily find the same bugs. Probably we are doing 
something wrong. I'll look into it in more details a bit later.

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

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