==========================================================================
[
18:16:35
]
attempting fuzz -
2
(
len: 50057
)
.
[
18:16:35
]
info: tx fuzz -
(
50057
bytes
)
- scanning
for
reply.
[
18:16:35
]
read
:
220
rosebud.washere.com ESMTP Postfix
(
Debian/GNU
)
250
rosebud.washere.com
==========================================================================
[
18:16:35
]
attempting fuzz -
3
(
len: 50057
)
.
[
18:16:35
]
info: tx fuzz -
(
50057
bytes
)
- scanning
for
reply.
[
18:16:36
]
read
:
220
rosebud.washere.com ESMTP Postfix
(
Debian/GNU
)
250
rosebud.washere.com
==========================================================================
One of the issues with using fuzzing attacks is that they may generate program
crashes. While this is ultimately the intent of the exercise, the question is how to
determine when the program has actually crashed. You can do it manually, of course,
by running the program under test in a debugger session so the debugger catches the
crash. The problem with this approach is that it may be hard to know which test case
caused the crash and, while finding a bug is good, just getting a program crash isn’t
enough to identify vulnerabilities or create exploits that take advantage of the vulner‐
ability. A bug, after all, is not necessarily a vulnerability. It may simply be a bug. Soft‐
ware packages can be used to integrate program monitoring with application testing.
You can use a program like
valgrind
to be able to instrument your analysis.
In some cases, you may find programs that are targeted at specific applications or
protocols. Whereas
sfuzz
is a general-purpose fuzzing program that can go after mul‐
tiple protocols, programs like
protos-sip
are designed specifically to test the SIP, a
common protocol used in VoIP implementations. The
protos-sip
package is a Java
application that was developed as part of a research program. The research turned
into the creation of a company that sells software developed to fuzz network proto‐
cols.
Not all applications are services that listen on networks for input. Many applications
take input in the form of files. Even something like
sfuzz
that takes definitions as
input, takes those definitions in the form of files. Certainly word processing, spread‐
sheet programs, presentation programs, and a wide variety of other types of software
use files. Some fuzzers are developed for the purpose of testing applications that take
files as input.
One program that you can use to do a wider range of fuzz testing is
zzuf
. This pro‐
gram can manipulate input into a program so as to feed it unexpected data.
Example 4-11
shows a run of
zzuf
against the program
pdf-parser
, which is a Python
script used to gather information out of a PDF file. What we are doing is passing the
