Targets are dropped

[vannussina]

Hi, I am trying to better understand the output of my fuzzing runs. I realized that Titan does not use all targets that I defined in my target file. Compared to other fuzzers, Titan uses less targets and I am trying to understand why. In the log_precond.txt file I see that some targets are dropped. I looked up the source code from the Beacon repo but the code must have changed a bit for Titan because it contains checks for usage of only 1 target and I can not find the word drop which I see in the log file. Other than that, fuzzing works. Is there still the limitation of dropping instructions that are PHI instructions?

[5hadowblad3]

One potential reason is that your targets do not exist in the bc file, which cannot be found by the debug info in LLVM IR (Noticed that compiler can slightly change the source code in IR). In this case, Titan will drop these targets.

[vannussina]

Okay I see.

Is there a limitation on cluster file sizes? I am trying to fuzz a static library using a simple program as harness. All works until I'm running the fuzzer command and it fails with Cannot open cluster file although the file path is correct and the cluster files itself are not empty. But I realized bug_conf_cluster has over 12 MB.

[5hadowblad3]

There is no explicit option to restrict the size of cluster file since it is hard to tell which information should be reduced without heuristics.

Still, you can use different granularity of the static analysis to make the cluster information more precise. For example, join-bound option consider paths more precisely. There are also different pointer analyses available in current prototype.

As it is one of the open questions we would like to tackle in future work, please let me know if you have more ideas on this issue.

Thanks and have fun!

[vannussina]

Thanks for your answer.

One potential reason is that your targets do not exist in the bc file, which cannot be found by the debug info in LLVM IR (Noticed that compiler can slightly change the source code in IR). In this case, Titan will drop these targets.

I double-checked and I create my targets with the IR code as a starting point. I get an IR instruction, check if it is not a PHI and if it has a DebugLoc. If that is the case, I use the corresponding source code location as my target. So that can not be the case I think :/

There is no explicit option to restrict the size of cluster file since it is hard to tell which information should be reduced without heuristics.

Still, you can use different granularity of the static analysis to make the cluster information more precise. For example, join-bound option consider paths more precisely. There are also different pointer analyses available in current prototype.

As it is one of the open questions we would like to tackle in future work, please let me know if you have more ideas on this issue.

Thanks and have fun!

I am sorry, I think I did not ask my question clearly. I am fine with big cluster files, but in my case, I get the error Cannot open cluster file although the file exists and contains information and the path is correct. What could be potential reasons for this? It's hard to find out myself as the source code for your modified AFL is not included in the repo.

Thanks for your patience!

[5hadowblad3]

Maybe you can send me your simplified bc and results?

I am busy with the relocation recently and will tackle this as soon as possible.

[vannussina]

Sure, I'll attach the out folder with the binary, log file, bc file and conf files and my build script. I was trying to fuzz libtiff using the tiff_read_rgba_fuzzer.cc file that oss-fuzz uses as well as harness. As far as I've seen, you have also fuzzed libtiff as part of the Magma benchmark for your evaluation, so I was expecting it to work. Thanks! out.zip

[5hadowblad3]

Hi, this issue is due to the missing details in the previous document.

To apply Titan for other projects outside the Magma benchmark, you need to enter the path information for the two cluster files inferred in the static analysis stage with options -s and -k. The usage example has been updated in the ReadMe.

Thanks for pointing out this issue!

[vannussina]

Thanks for pointing that out. I double checked and realized I also had an empty local environment variable which caused a mess for the arguments. Fuzzing worked now.

However, next I tried fuzzing libpng using the harness and linking to the instrumented library and again I am seeing a segfault during instrumentation as I described here in the Beacon repo. This seems weird to me as I already fuzzed libpng using their internal tool pngread as target and back then it worked. The error message is just [+] Static Analysis ./libpng/titan-fuzz.sh: line 48: 54313 Segmentation fault (core dumped) $FUZZ/prototype/precondInfer "$OUT/libpng_read.bc" --target-file=$SEED/cstest.txt --join-bound=1 > "$OUT/log_precond.txt" 2>&1 I attached my out files. libpng_out.zip

[5hadowblad3]

OK. We are working on patching that segmentation issue, which is related to the static analysis algorithm itself on some corner cases. Please stay tuned to that. We will update the two repositories after the code is updated recently. This issue is finished and closed.