Add ENV Variable to restart killed forkserver

[Lancern]

I use forkserver deferred initialization mode to increase fuzzing speed. However, for some unknown reasons yet, the forkserver crashes after some time. I think it might be better to automatically restart the forkserver after it crashes than simply terminate the fuzz process.

[domenukk]

As a quick fix, you can wrap your AFL call in a bash loop and set AFL_AUTORESUME=1.
In the long run we could consider restarting the forkserver, although it would be interesting to know why it happens (I don't think it ever should)

[vanhauser-thc]

@Lancern I disagree. if there is an issue where the forkserver crashes - it needs to be fixed. however I dont know why it should crash. it does basically very very little. can you share the setup?

[Lancern]

I'm fuzzing nodejs using a strategy similar to micro-fuzzing, i.e. the individual functions inside nodejs is tested directly rather than the whole program (More precisely, it is the functions that can be called directly from JavaScript, not arbitrary functions). Each test case consists of a sequence of functions and parameters to these functions, pretty much like syzkaller. Test cases are generated randomly and mutated by a custom mutator.

I checked out the last executed test case in the queue, and I found the test case contains a call to node::Kill, which behaves exactly like the syscall kill. If the parameters are appropriate (e.g. node::Kill(getppid(), SIGKILL)), the execution of this test case leads to the termination of the parent process, i.e. the forkserver.

[vanhauser-thc]

@Lancern great so it is not a bug in the forkserver :)

the correct solution is then to modify your target so that node::Kill(getppid(), SIGKILL)) cannot happend, e.g. bei return always 0 for getppid or something like that

[domenukk]

... or ldpreload a library that does this or overwrites kill.
Still @vanhauser-thc we could add an optional forkserver restart for this use-case (something like AFL_FORKSERVER_STICKY, because why not?
It's probably slower than the other options, but there is a clear use case.

[vanhauser-thc]

if it is optional and not a default and an env var (to save on command line parameters that we might need in the future) then why not

[Lancern]

@vanhauser-thc thanks for your advice. I have modified it and the forkserver no longer crashes (at least for a while).

I wonder another question: why is AFL_PERSISTENT discarded? I know AFL can automatically figure out whether the binary supports persistent mode, but what if the persistent signature is contained in a shared library that is loaded by the executable at runtime?

[vanhauser-thc]

I wonder another question: why is AFL_PERSISTENT discarded? I know AFL can automatically figure out whether the binary supports persistent mode, but what if the persistent signature is contained in a shared library that is loaded by the executable at runtime?

then you are using it wrong. persistent mode (__AFL_LOOP) must be in your own main() (or at least in the binary created) and not somewhere down in a library.

Also loading shared libs is a point of trouble. if you are sure you are loading instrumented libraries you are fine (if you want them with coverage), but if the same libraries exist on the system without instrumentation and because of a forgotten LD_LIBRARY_PATH these are loaded ... so its always better to compile static.

[domenukk]

I think the use case does exist.
Unicorn mode is such an example: python itself is not instrumented, the unicornafl.so is.
If it would load the wrong lib, the forkserver couldn't start so afl catches this.
for now @Lancern in theory you can use the -U switch to afl to get this result.