[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
