ocurrent / bun

tired of typing afl-fuzz? try bun!
MIT License
50 stars 10 forks source link

Report afl-fuzz errors #13

Open NathanReb opened 5 years ago

NathanReb commented 5 years ago

bun seems to mistake afl-fuzz errors and success in some cases.

For instance if my CPU's scaling governor isn't properly set, when running afl-fuzz I get the following error:

$ afl-fuzz -i awesome-list/fuzz/inputs -o output -- ./_build/default/awesome-list/fuzz/fuzz.exe @@
afl-fuzz 2.52b by <lcamtuf@google.com>
[+] You have 8 CPU cores and 2 runnable tasks (utilization: 25%).
[+] Try parallel jobs - see docs/parallel_fuzzing.txt.
[*] Checking CPU core loadout...
[+] Found a free CPU core, binding to #1.
[*] Checking core_pattern...
[*] Checking CPU scaling governor...

[-] Whoops, your system uses on-demand CPU frequency scaling, adjusted
    between 390 and 3906 MHz. Unfortunately, the scaling algorithm in the
    kernel is imperfect and can miss the short-lived processes spawned by
    afl-fuzz. To keep things moving, run these commands as root:

    cd /sys/devices/system/cpu
    echo performance | tee cpu*/cpufreq/scaling_governor

    You can later go back to the original state by replacing 'performance' with
    'ondemand'. If you don't want to change the settings, set AFL_SKIP_CPUFREQ
    to make afl-fuzz skip this check - but expect some performance drop.

[-] PROGRAM ABORT : Suboptimal CPU scaling governor
         Location : check_cpu_governor(), afl-fuzz.c:7337

and it exits with status 1.

If I now run it through bun I get the following:

$ bun -i awesome-list/fuzz/inputs -o output -- ./_build/default/awesome-list/fuzz/fuzz.exe @@
13:33.55:Fuzzers launched: [1 (pid=25163); 2 (pid=25164); 3 (pid=25165);
                            4 (pid=25166); 5 (pid=25167); 6 (pid=25168);
                            7 (pid=25169); 8 (pid=25170)].
13:33.55:[WARNING]Fuzzer 1 (pid=25163) has failed with code 1
No crashes found!
13:33.55:[ERROR]All fuzzers finished, but some crashes were found!

The output can get even more confusing if the afl error isn't triggered immediately and some other fuzzing processes were spawned.

It should be fairly trivial to detect whether afl-fuzz did find a crash or stopped for some other reason using the exit status and remove the confusing log telling the user crashes were found. It would then be even to better to forward its output to get better error message.

I'm as always happy to help with that and provide a patch if that's fine by you!

talex5 commented 3 years ago

I think the problem is that afl-fuzz writes the error message to stdout rather than to stderr. By default, stdout is hidden (unless you use -vv).