oss-fuzz integration of kryo

[0roman]

Hi all,

I prepared the integration CodeIntelligenceTesting/oss-fuzz@e770af6 of kryo into google oss-fuzz. This will enable continuous fuzzing of this project, which will be conducted by google. Bugs that will be found by fuzzing will be reported to you.

The integration makes only sense if someone will deal with the bug reports submitted by oss-fuzz. Are you interested in the integration? If yes, I would submit a pull request and I would provide your contact information for bug reports. I would need some contact information (email) of someone who would handle the bug reports.

For the Fuzzing of Java applications Jazzer is used. Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by Code Intelligence. It is based on libFuzzer and brings many of its instrumentation-powered mutation features to the JVM.
Jazzer has already found a lot of critical bugs in JVM applications.

If there are any questions regarding fuzzing or the oss-fuzz integration, it would be a pleasure for me to help.

[theigl]

That looks very interesting @0roman!

The integration makes only sense if someone will deal with the bug reports submitted by oss-fuzz. Are you interested in the integration? If yes, I would submit a pull request and I would provide your contact information for bug reports. I would need some contact information (email) of someone who would handle the bug reports.

Sure, I can deal with the bug reports. Contact info would be thomas at umschalt dot com.

If there are any questions regarding fuzzing or the oss-fuzz integration, it would be a pleasure for me to help.

I took a brief look at your current fuzzer implementations. What I don't understand is how the fuzzer manages to generate inputs that Kryo can actually parse, without the use of a dictionary. Does it generate random inputs and observe the coverage?

Most users of Kryo don't use the out-of-the box configuration options. The most common settings are probably setReferences(true) and the use of another default serializer such as CompatibleFieldSerializer. Would it make sense to add these options like it is done in the Jackson implementation?

[0roman]

@theigl okay, that is awesome.

I took a brief look at your current fuzzer implementations. What I don't understand is how the fuzzer manages to generate inputs that Kryo can actually parse, without the use of a dictionary. Does it generate random inputs and observe the coverage?

That is correct. Based on the feedback the input is mutated until new program paths are triggered. Input that triggers new paths is again mutated. Just generating and mutating bytecode that will be deserialized seems to be a good starting point for me.

Most users of Kryo don't use the out-of-the box configuration options. The most common settings are probably setReferences(true) and the use of another default serializer such as CompatibleFieldSerializer. Would it make sense to add these options like it is done in the Jackson implementation?

Sure, i can add them. Does it makes sense to have both configurations (one out of the box and the other one with CompatibleFieldSerializer and setReferences) tested?

[theigl]

That is correct. Based on the feedback the input is mutated until new program paths are triggered. Input that triggers new paths is again mutated. Just generating and mutating bytecode that will be deserialized seems to be a good starting point for me.

OK thanks for clarifying!

How does that fuzzer then distinguish between "expected" exceptions (i.e. malformed input) and potential bugs? Do we need to account for KryoExceptions that indicate a problem with the input?

Sure, i can add them. Does it makes sense to have both configurations (one out of the box and the other one with CompatibleFieldSerializer and setReferences) tested?

It would make sense to test all combinations:

Default, Default+References, Default+CompatibleSerializer, Default+References+CompatibleSerializer, ...

But we can also start with your current implementation and see how it goes and add additional configuration options later.

[theigl]

How does that fuzzer then distinguish between "expected" exceptions (i.e. malformed input) and potential bugs? Do we need to account for KryoExceptions that indicate a problem with the input?

My bad, I just saw that you already handle KryoException. I think we are good to go with your current implementation as a first version.

[theigl]

@0roman: I got the first report from the fuzzer yesterday. An exception other than KryoException was thrown when deserializing an invalid reference. I have just fixed that and will wait for the next check. I hope the reference=true case doesn't cause too many false positives because of unspecific exceptions.

[0roman]

@theigl: I am really happy to hear that. It should be fine. By the current configuration we have covered all preferred combinations.

[theigl]

Thanks @0roman! The initial implementation looks good now that coverage builds are working.