ifratric
commented
2 months ago Can you share the crashes that the other fuzzers found? The issue I see with your fuzzing setup is that you limit the input sample size to 50 (see: int read_max = 50;). While this is sufficient to construct a sample that goes out-of-bounds, depending on the stack layout created by the compiler, this might not be sufficient to corrupt anything on the stack and cause a crash.
For example, let's take the following (optimal!) 50-bye input:
()()()()()()()()()()()()()()()()()()()()()()()()()If I compile your target on Linux with either clang or gcc and use the above input, it isn't sufficient to cause a crash. I didn't do any testing on Windows, however I expect it to behave similarly.
However, if I remove the 50-byte limit from your harness, then Jackalope also finds a crash in several minutes. Here is an example hexdump of one of Jackalope-discoved crashes:
00000000 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 |(.'..)(.'..)(.'.|
00000010 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 |.)(.'..)(.'..)(.|
00000020 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 |'..)(.'..)(.'..)|
00000030 28 f0 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 |(.(.'..)(.'..)(.|
00000040 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 |'..)(.'..)(.'..)|
00000050 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 |(.'..)(.'..)(.'.|
00000060 e2 29 28 f0 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 |.)(.(.'..)(.'..)|
00000070 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 |(.'..)(.'..)(.'.|
00000080 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 |.)(.'..)(.'..)(.|
00000090 27 e1 e2 29 28 f0 28 f0 27 e1 e2 29 28 f0 27 e1 |'..)(.(.'..)(.'.|
000000a0 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 |.)(.'..)(.'..)(.|
000000b0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 |'..)(.'..)(.'..)|
000000c0 28 f0 27 e1 e2 29 28 f0 28 f0 27 e1 e2 29 28 f0 |(.'..)(.(.'..)(.|
000000d0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 |'..)(.'..)(.'..)|
000000e0 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 |(.'..)(.'..)(.'.|
000000f0 e2 29 28 f0 27 e1 e2 29 28 f0 27 e1 e2 29 |.)(.'..)(.'..)|However, even if Jackalope already discovers it (without the 50-byte limit), I did take an opportunity to tweak the default Jackalope mutator settings in https://github.com/googleprojectzero/Jackalope/commit/ad14a3eecf3a720485566376ab722a0f2b31e950. With those, Jackalope finds this bug even faster.
ssarfaty
hi, i have tested the following code of the known "copy_it" function from the paper: https://www.usenix.org/system/files/conference/woot12/woot12-final26.pdf
in afl and afl++ (takes about 1-3 min) and libfuzz (found in first seconds) this bug is found easily (compiled with GCC with target -m32 on linux) - in the input folder i have created on file with a text of "hello" and that's it. no real input but it was enough.
i haven't been able to find the issue with Jackalope while i used visual studio (2019) - Release - x86 with the following command given to the fuzzer:
C:\Jackalope-main\Jackalope-main\build\Release>fuzzer.exe -in input -out output -t 1000 -delivery file -instrument_module copy_it.exe -target_module copy_it.exe -target_method main -nargs 1 -cmp_coverage -- copy_it.exe @@i have used the "main" function since the function becomes inline. i have run the following code for more than a day without any luck ..can you think on why this happen with your type of technique / mutators that cause this to be not effective ?
define BUFFERSIZE 25
define TRUE 1
define FALSE 0
include / Needed only for _O_RDWR definition /
include
include
include
include
include
pragma warning(disable : 4996)
int copy_it(char input) { char lbuf[BUFFERSIZE]; char c, p = input, d = &lbuf[0]; char ulimit = &lbuf[BUFFERSIZE - 10]; int quotation = FALSE; int rquote = FALSE;
}
//function taken from: https://gist.github.com/leonid-ed/5b9161531afdafe65bca void hexDump(char desc, void addr, int len) { int i; unsigned char buff[17]; unsigned char pc = (unsigned char)addr;
}
int main(int argc, char* argv[]) { int read_max = 50; unsigned int bytes_read = 0; char data[50];
}
Thanks, shai