Angora Crashes on start when fuzzing LAVA-M

[zhangysh1995]

I followed the tutorial in docs to build LAVA-M, and use the following command to fuzz base64:

./angora_fuzzer -i ../lava-m/base64/fuzzer_input/ -o ../output/base64_test -t ./base64.tt -- ./base64.fast -d

And it crashes on startup, and shows this message:

thread 'main' panicked at '
If your system is configured to send core dump, there will be an
extended delay after the program crash, which might makes crash to
misinterpreted as timeouts.

You can modify /proc/sys/kernel/core_pattern to disable it by:
# echo core | sudo tee /proc/sys/kernel/core_pattern
', fuzzer/src/check_dep.rs:20:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:491
   5: std::panicking::begin_panic
   6: angora::check_dep::check_dep
   7: angora::fuzz_main::fuzz_main
   8: fuzzer::main
   9: std::rt::lang_start::{{closure}}
  10: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  11: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:102
  12: std::rt::lang_start_internal
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  13: main
  14: __libc_start_main
  15: _start

Is this problem related to core dump mode? But it is required by AFL, so this was already set before. How should I fix this poblem?

[zhangysh1995]

And because the default parameter -t for timeout in AFL is changed, could I still have a way to set time limit?

[zhangysh1995]

I have the same issue when following the instructions to fuzz base64 inside the docker container.

root@f8a44c8e576a:/angora# ./angora_fuzzer -i ../data/base64/fuzzer_input/ -o /root/output/base64 -t base64.tt -- base64.fast -d thread 'main' panicked at ' If your system is configured to send core dump, there will be an extended delay after the program crash, which might makes crash to misinterpreted as timeouts. You can modify /proc/sys/kernel/core_pattern to disable it by: # echo core | sudo tee /proc/sys/kernel/core_pattern ', fuzzer/src/check_dep.rs:20:9 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:71 2: std::panicking::default_hook::{{closure}} at src/libstd/sys_common/backtrace.rs:59 at src/libstd/panicking.rs:211 3: std::panicking::default_hook at src/libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:491 5: std::panicking::begin_panic 6: angora::check_dep::check_dep 7: angora::fuzz_main::fuzz_main 8: fuzzer::main 9: std::rt::lang_start::{{closure}} 10: std::panicking::try::do_call at src/libstd/rt.rs:59 at src/libstd/panicking.rs:310 11: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:102 12: std::rt::lang_start_internal at src/libstd/panicking.rs:289 at src/libstd/panic.rs:398 at src/libstd/rt.rs:58 13: main 14: __libc_start_main 15: _start

[spinpx]

Have you ran echo core | sudo tee /proc/sys/kernel/core_pattern?

[zhangysh1995]

I already ran echo core | sudo /proc/sys/kernel/core_pattern on my server. And I could run AFL smoothly on the server. Is there any differences between this command and the one you gave?

The content of the file on the server:

yushanzhang@ubuntu:~$ cat /proc/sys/kernel/core_pattern
/apollo/data/core/core_%e.%p

And it is difficult to get this command run inside a docker container, because docker doesn't allow it. One explanation is here.

This is content of the file inside the docker container.

root@f8a44c8e576a:~# cat /proc/sys/kernel/core_pattern
/apollo/data/core/core_%e.%p

[spinpx]

Angora checks your core_pattern's content to ensure if it is core. Obviously, it is not core in your server. Please run this command outside of docker, and restart the docker container again.