Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzer terminates on System.exit() #7

Open
benjholla opened this issue Feb 25, 2018 · 3 comments
Open

Fuzzer terminates on System.exit() #7

benjholla opened this issue Feb 25, 2018 · 3 comments

Comments

@benjholla
Copy link

benjholla commented Feb 25, 2018

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants