Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.
After reading this chapter, hopefully you have come away with some ideas about what is useful in iFUZZ. Equally important is that you have identified some of the weaknesses of iFUZZ. What follows are some postdevelopment observations made about iFUZZ.
First of all, iFUZZ does not take into account the possibility of crashing the system, other than by using a few hard-coded sleep values to try to keep the load down. It would be a nice feature to be able to analyze the system load to see if this sleep time needs to be increased to keep the system from hanging or causing false negatives or false positives, which can occur under heavy load.
It would be desirable to have a specialized option that will determine the approximate string length or absolute minimum required to trigger a crash. This is a fairly trivial feature, but would save a few moments here and there.
Another trivial feature missing from iFUZZ is the ability to automatically locate all of the setuid and setgid binaries on the system. This is another time-saving feature.
The ability to parse the options from a given binary would be a great feature, but is probably not trivial to implement. If the user could specify a binary, and iFUZZ could automatically determine which flags and options the application required, that would result in an intelligent and complete fuzz with minimal user interaction. Of course, this is not a trivial implementation, as many applications use many different formats. Even after a fairly complete implementation of this feature, a new application with a new style of usage function could be unparsable with the current code. That being said, it is not completely impossible to make the feature extensible so that users can add new formats for different applications they encounter.
Something we found to be trivial to implement, yet invaluable to have, was the C code generation capability. Being able to have a C language program produced after a crash means the vulnerability can be reproduced manually in almost no time. The code generated might even be used as the basis for an exploit. This saves time for the exploit developer, especially when fuzzing a weak system with many crashes when the time of writing skeleton C programs to trigger the vulnerability begins to add up.