Boofuzz can take a while to finish after fuzzing completed (v0.4.0)

[boondoggler]

Hi,

I have a perfectly functioning 0.2.0 python script which ends with:

.
.
.
session.fuzz()
print("Fuzzing Finished")

With 0.2.0, the fuzzer finishes and the script prints the Finished message and terminates correctly.

With 0.4.0, the fuzzing "appears" to finish (i.e. the webserver stops logging new payload mutations, as does the boofuzz web interface), but the Boofuzz never actually terminates. Web.png shows Boofuzz on its last mutation correctly, but the Request section is still running.

Looking at Wireshark output (wireshark.png), we see my last web server response (packet 64000) then there is just traffic relating to updating the test cases (packet 64005 onward).

Any ideas? Am I being a dork?

)

[boondoggler]

See below

[boondoggler]

Im gonna re-open this again. I've rebooted the box and Im having the same issue from cold start.

[boondoggler]

So, further digging. If i have 1 primitive in a block it will close straight after fuzzing has ended. In my python script:
.
.
.
header
.
.
if s_block_start("post blob"):
s_byte(0x41, name = 'blah1', signed=False, full_range=True, fuzzable=True)
s_byte(0x42, name = 'blah2', signed=False, full_range=True, fuzzable=True) <--- comment out and closes almost immediatly
s_block_end()

So, it looks like it does close eventually with more than 1 block, but Boofuzz (or something in my script) is churing away in the background after the permutations have finished.

[SR4ven]

Thanks for the detailed report @boondoggler.
Could you please provide the last few lines from the console log as well as a script with which we can try to reproduce your findings?

The webinterface only updates once a test case has finished, so we can't see where exactly boofuzz gets stuck from the output of the webinterface.

The easiest way to find out where the delay comes from would be to use a debugger. That way you could simply pause the script when it appears to be stuck.

Just to make sure, the session option keep_web_open is set to false right?

[boondoggler]

Hi, Thanks for your pointers. Will look into debug option. See attached console output. Yes keep_web_open is False

So as you can see, it does eventually finish. This was captured using the Python script text file attached (possibly I should add a time stamp to the final "Finished" Banner to show how long it can take...)

boofuzz.txt

[boondoggler]

A quick look in a debugger, the code seems to be going around and around in these areas:

block.py (mutations) 68-69
fuzzable.py (get_mutations) 136-146
sessions.py (_generate_n_mutations_for_path) 1461-2

Unsuprising really as the Request: section is still active after fuzzing has stopped. Sorry wont have anytime until next week to look at this now.

[tanmayv25]

We are also seeing a hang-up in our fuzz test when moving from boofuzz 0.3.0 to 0.4.0.
See here.

[SR4ven]

Thanks for looking into this @boondoggler.
From the information you provided, it seems like boofuzz is generating lots of duplicate mutations. Because _mutations_contain_duplicate spots those duplicates, they are never sent to the target but that whole process seems to take a lot of time.
I'll see if we can optimize that part or at least generate less duplicates.

[SR4ven]

I could reproduce the issue now. The root of the long wait time seems to be the combinatorial test case generation which seems to be generating huge amounts of duplicates which are recognized as such and are skipped.

boofuzz/boofuzz/sessions.py

Lines 1470 to 1471 in e1f0ebf

	for mutations in self._generate_n_mutations_for_path_recursive(path, depth=depth):
	if not self._mutations_contain_duplicate(mutations):

When debugging we jump between those two lines.
Any idea how to fix this @jtpereyda?

A workaround is to use Session.fuzz(max_depth=1). That disables combinatorial fuzzing.