afl-showmap showing segfault (Program killed by signal 11) whereas binary does not

[bernard....@gmail.com]

I'm using afl-showmap for the first time. 

I compiled my binary with afl and I' now trying to check if it worked well. 

To do that, I discovered afl-showmap. Here is the command I'm using: 
afl-showmap -o /tmp/test.txt -- ./binary

The binary I'm using does not ask any input. I get a segfault :

+++ Program killed by signal 11 +++

[-] PROGRAM ABORT : No instrumentation detected

However, if I run my binary alone, I do not get any segfault.

I have the feeling that afl-showmap is not running my program the same way that I would do by directly executing it on my terminal. 
Indeed, my binary starts by printing some indications. When I use strace/gdb on the binary, I don't see any segfault. In afl-showmap I don't see anything. It directly gets killed.

Is afl-showmap calling the right dynamic linker when calling my binary ? Is there another reason like that would cause this segfault ?  

Thanks you in advance for your help

[Jakub Wilk]

* bernard....@gmail.com, 2018-12-26, 16:30:

>Is there another reason like that would cause this segfault ?

afl-showmap sets tight virtual memory limit. Most likely your program
ran out of memory and didn't handle it well.

--
Jakub Wilk

[Peter Gutmann]

Full-speed Fuzzing: Reducing Fuzzing Overhead through Coverage-guided Tracing

https://arxiv.org/abs/1812.11875

Of coverage-guided fuzzing's three main components: (1) testcase generation,
(2) code coverage tracing, and (3) crash triage, code coverage tracing is a
dominant source of overhead. Coverage-guided fuzzers trace every testcase's
code coverage through either static or dynamic binary instrumentation, or more
recently, using hardware support. Unfortunately, tracing all testcases incurs
significant performance penalties---even when the overwhelming majority of
testcases and their coverage information are discarded because they do not
increase code coverage. To eliminate needless tracing by coverage-guided
fuzzers, we introduce the notion of coverage-guided tracing. Coverage-guided
tracing leverages two observations: (1) only a fraction of generated testcases
increase coverage, and thus require tracing; and (2) coverage-increasing
testcases become less frequent over time. Coverage-guided tracing works by
encoding the current frontier of code coverage in the target binary so that it
self-reports when a testcase produces new coverage---without tracing. This
acts as a filter for tracing; restricting the expense of tracing to only
coverage-increasing testcases. Thus, coverage-guided tracing chooses to
tradeoff increased coverage-increasing-testcase handling time for the ability
to execute testcases initially at native speed. To show the potential of
coverage-guided tracing, we create an implementation based on the static
binary instrumentor Dyninst called UnTracer. We evaluate UnTracer using eight
real-world binaries commonly used by the fuzzing community. Experiments show
that after only an hour of fuzzing, UnTracer's average overhead is below 1%,
and after 24-hours of fuzzing, UnTracer approaches 0% overhead, while tracing
every testcase with popular white- and black-box-binary tracers AFL-Clang,
AFL-QEMU, and AFL-Dyninst incurs overheads of 36%, 612%, and 518%,
respectively.

[Sanjeev Kumar Das]

I encountered similar issues while fuzzing my application with afl-fuzz. I got many crashes because of memory limit set by afl-fuzz, as it runs out of memory.

What would be the appropriate method to set this memory limit with afl-fuzz?

Regards
Sanjeev

> --
> You received this message because you are subscribed to the Google Groups "afl-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.