AFL with ASAN

[cb]

I am trying to find the buffer overflow bug in the source code main.c below with AFL:

int main()

{

  long val=0x41414141;

  char buf[20];

  printf("Correct val's value from %x -> 0xdeadbeef!\n", val);

  printf("Here is your chance: ");

  scanf("%24s",&buf);

  printf("buf: %s\n",buf);

  printf("val: 0x%08x\n",val);

  if(val==0xdeadbeef)

  {

   printf("Success\n");

  }

  else

  {

    printf("NOPE !!!!\n");

    exit(1);

  }

  return 0;

}

I compiled main.c with AFL-GCC as such: 

CC=/disk1/home/cbhowmik/AFL/afl-2.52b/afl-gcc ./configure  test_program

My initial test-case is:

"AAAAAAAAAAAAAAAAAAAAAAAA".

Kicked off AFL-fuzzer as such: 

./afl-2.52b/afl-fuzz  -i ./testcase_dir/ -o ./findings_dir_1/ ./test_program

I left AFL running for > a day and saw no crash. Realized the binary execution is not supposed to generate a crash or signal exception. Got tips to use Address Sanitizer instrumentation with AFL-GCC. So I recompiled main.c with ASAN options like below: 

AFL_USE_ASAN=1 ./configure CC=/disk1/home/cbhowmik/AFL/afl-2.52b/afl-gcc; AFL_USE_ASAN=1 make clean all

But when I ran AFL against my binary, AFL crashed with this error: 

] Whoops, the target binary crashed suddenly, before receiving any input

    from the fuzzer! Since it seems to be built with ASAN and you have a

    restrictive memory limit configured, this is expected; please read

    docs/notes_for_asan.txt for help.

[-] PROGRAM ABORT : Fork server crashed with signal 6

         Location : init_forkserver(), afl-fuzz.c:2201

I looked into notes_for_asan.txt document. I followed options to recompile my binary with -m32 flag,and ran afl-fuzz with -m 800 option to restrict  program's virtual memory, but i still get error with AFL-fuzz. 

I tried ulimit -v unlimited, but that didn't solve the problem either. 

At this point I am not sure how to use asan with afl fuzzing effectively. From the error it looks like OOM bug, but compiling as 32 bit didn't solve the problem either. 

Is there a best known method to fuzz binaries that don't necessarily generate a crash due to a memory corruption/overwrite bug with AFL?

Any help is highly appreciated.

Thanks in advance.

[Jakub Wilk]

* cb <chandnib...@gmail.com>, 2018-03-30, 16:12:

> long val=0x41414141;
> char buf[20];
>
> printf("Correct val's value from %x -> 0xdeadbeef!\n", val);

You have type mismatch here: val is long int, but %x expects an int.

>My initial test-case is:
>"AAAAAAAAAAAAAAAAAAAAAAAA"

This is not a good initial test case, because it already overflows the
buffer.

--
Jakub Wilk

[cb]

Posting again, this last email I wrote yesterday never showed up on this group thread. 

Hi Jakub,

Thanks for the pointers. 

I am just using a small CTF challenge code built by someone else for playing with AFL fuzzing. I do see your point though, should have used %lx format instead...

But I guess 0x41414141 is only 4 bytes and probably being padded to 8 bytes while being stored in val as long int. And then I am using %x during printing, which is probably printing out only 4 bytes of val (0x41414141)). 

I replaced the test case I had with just AAAA. AFL-fuzz still complained about bad test case. So I completely removed my test case and now AFL shows 1 crash. I am yet to figure out how to interpret AFL's output or crash data. 

Since AAAA shouldn't be overflowing the buffer, but also didn't work as a good test case, I am wondering if there is a best known method for crafting initial test cases to help AFL-fuzz work better? Thanks in advance. 

Thanks,

cb

[Jakub Wilk]

* cb <chandnib...@gmail.com>, 2018-04-02, 12:22:

>I guess 0x41414141 is only 4 bytes and probably being padded to 8 bytes
>while being stored in val as long int. And then I am using %x during
>printing, which is probably printing out only 4 bytes of val
>(0x41414141)).

Yeah, I doubt it makes a practical difference (at least on mainstream
architectures), but I think formally it's undefined behavior. (NB, the
compiler should have warned you about this.)

>I replaced the test case I had with just AAAA. AFL-fuzz still
>complained about bad test case.

Apparently under ASAN this:

scanf("%24s", buf);

writes whole 25 bytes, even when the input is shorter. To me, this
sounds like a bug in ASAN. (But hey, it found a bug in your code even
without fuzzing. :-P)

>So I completely removed my test case

I don't follow. At least one input is a strict requirement for AFL.

Hmm, I guess you just left some whitespace in the input file? That would
make AFL happy and avoid the ASAN crash.

--
Jakub Wilk