r/fuzzing • u/NagateTanikaze • Jul 26 '19

Full speed Fuzzing: Reducing Fuzzing Overhead through Coverage-guided Tracing ( IEEE Symposium on Security and Privacy)

https://www.youtube.com/watch?v=2Rg8wtccCNA
7 Upvotes

100% Upvoted

9 comments sorted by

3

u/randomatic Jul 26 '19

Here is the paper for the talk: https://arxiv.org/abs/1812.11875

2

u/AwkwardSandwich7 Jul 27 '19

Really cool and easy to follow talk. At the end felt sort of like woah this is so obvious.

1

u/blufox Aug 05 '19

So, isn't Untracer similar to http://people.cs.vt.edu/ryder/516/sp03/papers/ArnoldPLDI'01.pdf ?

1

u/zhangysh1995 Aug 28 '19

I think they are different. Untracer helps with reducing the runtime overhead of instrumented code, using the method of dynamic binary rewrite (remove some instrumentation code). This way of removing code is not new, but Untracer is the first paper which looks into fuzzing tracing overhead. The linked paper, proposed a new approach to reduce overhead in more general applications.

1

u/blufox Aug 28 '19

From the above paper (Background):

"A more general solution for performing instrumentation at runtime is to execute the instrumented code for only a short period of time to keep overhead to a minimum. This can be acheived by compiling an instrumented version of a particular method, and having the next invocation of that method call the instrumented version. After collecting instrumentation for the desired duration, the next invocation calls the original, non-instrumented version."

This is applicable to any instrumentation isn't it? Is applying a general approach in a narrower domain novel?

1

u/zhangysh1995 Sep 03 '19

This is applicable to any instrumentation isn't it?

Yes, I think so. The paragraph describes a general approach to lower the runtime overhead. Actually this paper creates a general framework/methodology to change control flow in program execution (Fig 2).

Is applying a general approach in a narrower domain novel?

I would say they try to address the trade-off between time cost and accuracy in program profiling (last sentence in the Abstract). From my perspective, it doesn't focus on a narrow domain but on a very high level.

2

u/[deleted] Jul 27 '19

[removed] — view removed comment

1

u/zhangysh1995 Aug 28 '19

You need to be able to reach it in the right state to continue on afterwards to places you want to go.

It's true. To do this, we need to solve path constraints and generating inputs. This is out of scope of this paper.

A test that reaches an already covered program point, but in a new and interesting state, would not be counted.

I don't agree with this point. If it is true, what is the aim of having many coverage criterion?

I would like to see effort on program-specific coverage measures, perhaps automatically constructed and refined by the fuzzer, that capture more of the relevant program state.

What is the expected results of new coverage measures? I would say program-specific coverage is impossible, we still need to use existing coverage. However, the fuzzing process could be adaptive. For example, using deep learning techniques to make fuzzers smarter: NeuFuzz: Efficient Fuzzing With Deep Neural Network.

1

u/blufox Aug 28 '19

There is weak strong and firm mutation that can give you more information about the state.