codenote / bunny-the-fuzzer Goto Github PK

Why using -O3 optimization?

Is it essential had has a reason?

Note: I am packaging fuzzer for fedora and consider this as an issue unless
there is a specific reason.

Consider this:

# cat foo.c 
int foo(int foo)
{
        return foo;
}
# ./bunny-gcc -c foo.c 
[bunny] bunny-gcc 0.93-beta (Dec  1 2009 19:59:23) by <[email protected]>
[bunny] STAGE 1/3: Precompiling 'foo.c'...
[bunny] STAGE 2/3: Injected 3 hooks into 'foo.c' (22 tokens).
[bunny] STAGE 3/3: Compiling binary to default .o file(s)...
foo.c: In function ‘foo’:
foo.c:2: error: called object ‘foo’ is not a function
[bunny] PROGRAM ABORT: gcc error (exit code 1) [wait_execvp(), bunny-gcc.c:267]

Although it compiles fine with "gcc -c foo.c".

I tried to run bunny on a program under ubuntu / x86. It works without
problems.
Then I switched to debian / amd64, and bunny started behaving strangely. It
claims, that there was no trace for 2000ms, even though it wasn't running
that long (1.794 total) and did much more execs. Is there any more
debugging info I can provide?

--->8---

Bunny the Fuzzer - a high-performance instrumented fuzzer by
<[email protected]>
--------------------------------------------------------------------------------
-

  Code version : 0.93-beta (Jul 14 2009 10:07:27)
    Start date : Tue Jul 14 10:35:15 2009
   Target exec : ../opensips-1.5.1-notls/opensips
  Command line : <none>
   Input files : ../test/in_dir/
   State files : ../test/out_dir/
   Fuzz output : <target stdin>
   Random seed : 05c21ca2
  All settings : T=5000,2000 B=8+1 C=8+1,8 A=10 X=9,19,27+8 R=4096*8
L0=32,16 r00 c=2 U0 E=500 f0 k0 F=0

[+] Flow controller launched, 398 bytes fuzzable.

=== Fuzzing cycle 0/0 (../test/in_dir) ===

[+] New call path - process calibration: ..DONE (full mode)
    Variations detected for 246/632 function parameters.
    Tracing 1 process, 281 functions, 398 bytes fuzzable
(c=40288b2056b006a1 p=76f4a5766249146f)
[+] Attempting variable window walking bit flipping (1/8).
    + New call path stored at '../test/out_dir/case000/000'
(c=ae4f4c13b8cc9145).
      Triggered by flipping 1 bits at bit offset #0.
    + New call path stored at '../test/out_dir/case000/001'
(c=b3b0e6864b1af20f).
      Triggered by flipping 1 bits at bit offset #3.
    + New call path stored at '../test/out_dir/case000/002'
(c=7590adcbef976bdb).
      Triggered by flipping 1 bits at bit offset #8.

+++ FAULT CONDITION DETECTED +++
Diagnosis : stall (no trace output for 2000 ms)
Capture   : ../test/out_dir/FAULT000/003
Trigger   : flipping 1 bits at bit offset #12.

[!] Fuzzing cycle terminated on abort condition (15 execs).

=== Fuzzing cycle 1/3 (../test/out_dir/case000/000) ===

[+] New call path - process calibration: .^C+++ Fuzzing stopped on signal 2 +++
./bunny-main -M500 -i ../test/in_dir -o ../test/out_dir   0.00s user 0.01s
system 0% cpu 1.794 total

What steps will reproduce the problem?
1. test a program that connects via UDP and requires empty .keep files 
2. run bunny on it.
3. If bunny does something which cases the program to terminate just when bunny 
is expecting a response, fuzzing hangs.

What is the expected output? What do you see instead?

bunny-flow gets stuck in commit_data_fd waiting for data as specified by an 
empty .keep file. In the tcp case, (I assume) the read will terminate
because it will notice that the socket is not connected. This can't happen for 
UDP.

What version of the product are you using? On what operating system?
0.93-beta
Linux xl-cbga-21 2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:33:05 EDT 2009 x86_64 
x86_64 x86_64 GNU/Linux

Please provide any additional information below.

I hacked my version by setting SO_RCVTIMEO equal to BUNNY_MAXTIME in 
commit_connect (in the udp case). This requires BUNNY_MAXTIME to be passed to 
bunny_flow.

$ make
cc -Wall -O3 -funroll-loops -fno-strict-aliasing -ffast-math
-Wno-pointer-sign bunny-gcc.c  -o bunny-gcc -lcrypto -lm 
bunny-gcc.c: In function ‘insert_hooks’:
bunny-gcc.c:721: warning: format ‘%u’ expects type ‘unsigned int’, but
argument 6 has type ‘size_t’
cc -Wall -O3 -funroll-loops -fno-strict-aliasing -ffast-math
-Wno-pointer-sign bunny-trace.c  -o bunny-trace -lcrypto -lm 
/var/folders/8u/8uiW+GhrGka2OlIHiT1fsU+++TI/-Tmp-//ccuR0ISA.s:477:invalid
character '(' in mnemonic
make: *** [bunny-trace] Error 1

What version of the product are you using? On what operating system?

$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

What steps will reproduce the problem?
1. unzip bunny source code
2. from that directory run cppcheck --enable=all -f .
3.

What is the expected output? What do you see instead?
[bunny-main.c:507]: (error) Common realloc mistake: 'queue_fn' nulled but not 
freed upon failure
[bunny-main.c:508]: (error) Common realloc mistake: 'queue_ck' nulled but not 
freed upon failure
[bunny-main.c:509]: (error) Common realloc mistake: 'queue_af' nulled but not 
freed upon failure


What version of the product are you using? On what operating system?
0.93
Scientific Linux 6.x 

Please provide any additional information below.
queue_fn = realloc(queue_fn,(queue_len + ALLOC_CHUNK) * sizeof(_u8*));
queue_ck = realloc(queue_ck,(queue_len + ALLOC_CHUNK) * sizeof(struct 
bunny_traceitem*));
queue_af = realloc(queue_af,(queue_len + ALLOC_CHUNK) * sizeof(_u8));
if (!queue_fn || !queue_ck || !queue_af) fatal("out of memory");

If I read it correctly we should be doing a free to take care of the realloc 
that failed.

The check generates some other things like style messages and warning messages 
which can also be addressed depending on their nature.  

does it work with x86_32, x86_64, ia64, amd64, ppc, ppc64, sparc?
May someone confirm for which of above it has been tested as working ?
For which it may work and for which it is not expected to work ?

What steps will reproduce the problem?
1. Get a project that uses C++ (e.g. poppler PDF library)
2. CXX=/path/to/bunny ./configure

What is the expected output? What do you see instead?
I'd like it to instrument the .cpp and .cc files. Instead, I only get:
checking dynamic linker characteristics... [bunny] bunny-gcc 0.92-beta 
(Nov 17 2007 09:42:15) by <[email protected]>
[bunny] No .c files to process spotted, will not install hooks.
[bunny] STAGE 3/3: Compiling and linking executable to default 
location...

What version of the product are you using? On what operating system?
0.9.2, on a linux (fedora 7) system

Please provide any additional information below.
I have no idea whether this is even technically possible. It'd be nice 
though.