isstac / kelinci

AFL-based fuzzing for Java
Apache License 2.0
231 stars 53 forks source link

Fuzzer terminates on System.exit() #7

Open benjholla opened 6 years ago

benjholla commented 6 years ago

Hi thanks for sharing your project. If my Java program that I am fuzzing calls System.exit it terminates the program including the instrumentation relay sever. Any ideas how to deal with this aside from removing System.exit callsites or somehow catching and aborting JVM shutdowns? Is there a way to automatically restart the application and continue fuzzing?

rodykersten commented 6 years ago

Hi Ben, thanks for your feedback. I was thinking about this a while ago. I think a good approach would be to have the instrumentor replace such calls with an exception. This is not currently implemented though.

benjholla commented 6 years ago

Maybe we could just hack it into the Kelinci server side and block shutdowns all together. Exceptions are cleaner in a sense that the fuzzer would likely see it as an error, but it could silently change behavior of the program if the exception was caught by an existing exception handler so it would be tricky on the instrumentation side to get right. Throw an exception, walk up the potential call stack check if it could be in a trap region and then add logic to catch your special exception (check class type or message maybe to identify it) and then rethrow and repeat all the way up the call stack.

Something like this might work for quick and dirty: https://morbidjava.blogspot.com/2017/02/how-to-prevent-jvm-termination-using.html

benjholla commented 6 years ago

Another design I wondered about would be to have the Kelinci server run in its own Java process and then use Runtime.exec to launch a second JVM process and execute it. Potentially you could check return status or outputs streams to know failure or no failure. This would handle JVM crashes as well, but would be much slower since you have to spin up a new JVM each fuzz input.