REVIEW: "Fuzzing", Michael Sutton/Adam Greene/Pedram Amini
- BKFUZZNG.RVW 20071005
"Fuzzing", Michael Sutton/Adam Greene/Pedram Amini, 2007,
%A Michael Sutton
%A Adam Greene
%A Pedram Amini
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%G 0-321-44611-9 978-0-321-44611-4
%I Addison-Wesley Publishing Co.
%O U$54.99/C$68.99 416-447-5101 fax: 416-443-0948 bkexpress@...
%O Audience a+ Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 543 p.
%T "Fuzzing: Brute Force Vulnerability Discovery"
In the foreword, H. D. Moore states that fuzzing is the submission, to
a system, of miscellaneous inputs in order to find vulnerabilities,
and that it is more art than science.
In the preface, the authors assert that, since it is important to have
as many people as possible finding vulnerabilities in our
applications, the book is written not only for researchers, but for
the general public and those with no background in the idea and
activity of fuzzing.
Part one provides background information and concepts. Chapter one
outlines the three basic types of vulnerability discovery: white box,
utilizing source code and other developer materials; black box,
submitting inputs and observing the results; and gray box, using tools
such as disassemblers and debuggers. A definition of fuzzing is
attempted in chapter two, discussing boundary values analysis
(submission of inputs that straddle the line between acceptable and
improper), but notes that fuzzing goes beyond this level of activity.
There is brief mention of mutation-basing (modification of input
described as acceptable) and generation-basing (creation of test data
from the specification of the format). Fuzzing methods are supposed
to be the topic of chapter three, but it generally lists different
types of programs (based on the types of applications they test).
Different types of data representation are mentioned in chapter four.
The requirements for successful fuzzing, discussed in chapter five,
are basically the best possible understanding of the system under
test, the ability to determine when an effect has been created, and
care in recording attempts and results.
Part two examines a variety of application target types, and the
automation of fuzzing activities. Chapter six lists some tools, and
notes some factors in programming test generation programs.
Subsequently, chapters follow a pattern of an initial discussion of a
specific category of intended quarry (environment variables and
arguments in chapter seven) and then automation of fuzzing for that
purpose (environment parameters in chapter eight). The targets are
Web applications (nine and ten), file formats (eleven, with automation
for UNIX in twelve, and Windows in thirteen), network protocols
(fourteen, fifteen, and sixteen), Web browsers (seventeen and
eighteen), and in-memory fuzzing (nineteen and twenty).
Part three introduces advanced fuzzing technologies. Fuzzing
frameworks, described in chapter twenty-one, are applications for
specifying formats and generating ranges of test and probe input data
to be used for submission to programs. It is difficult to find a
consistent thread for chapter twenty-two, but the topic seems to have
something to do with general programmatic approaches that may have
promise for the automation of fuzzing. While fuzzing can create
failures, and therefore note the existence of faults, in a program, it
cannot help us to identify vulnerabilities to be addressed unless we
can distinguish the part of the application that is responsible for
the malfunction. Chapter twenty-three explores this idea under the
title of fuzzer tracking, or code coverage, and notes some of the
utilities that can be of assistance, but doesn't do a good job of
explaining the necessary functions and concepts. Intelligent fault
detection, in chapter twenty four, is related to the material in
twenty-two, although on a more generic level.
Part four is a kind of summary, with "Lessons Learned" (and the
potential for the use of fuzzing in software development) in chapter
twenty-five. The title "Looking Forward," in twenty-six, would
normally lead the reader to expect some examination of future
directions, but instead there is a list of some advanced fuzzing
programs to close off the book.
This work does delineate the concepts involved in probing and testing
of software through random or semi-random input submission. For those
managing the software development process, these ideas are helpful,
although the book may seem a trifle long to that audience. For those
more directly involved in testing, the text may seem frustrating at
times: either simplistic, for experienced testers, or not detailed
enough, for quality assurance people just getting started in technical
explorations. Still, this is the most complete volume in the field so
far, easily exceeding Beaver's "Hacking for Dummies" (cf.
BKHACKDM.RVW), Chirillo's "Hack Attacks Testing" (cf. BKHKATTS.RVW),
or "The Software Vulnerability Guide" (cf. BKSWVLGD.RVW). Andrews'
and Whittaker's "How to Break Web Software" (cf. BKHTBWSW.RVW) has a
higher level of writing, but is more specialized, so Sutton, Greene,
and Amini have provided a useful and more general guide.
copyright Robert M. Slade, 2007 BKFUZZNG.RVW 20071005
====================== (quote inserted randomly by Pegasus Mailer)
rslade@... slade@... rslade@...
Do not fold, spindle or mutilate - originated by Charles A. Phillips