Project DescriptionCS161 Computer Security, Spring 20081 OverviewThe goal of this project is to implement a “fuzzer”, or fuzz tester. Fuzztesting is one way of attempting to discover security vulnerabilities in codeimplementing a network protocol or otherwise processing potentially mali-cious input. The concept of a fuzzer is simple; it repeatedly runs a programwhich is being evaluated on a series of automatically generated inputs. Ifsome input causes the program being tested to crash with a memory accessviolation, the program has failed the test and may have an exploitable secu-rity vulnerability. By generating inputs either partly or completely randomly,the fuzzer can rapidly run large numbers of tests without human supervisionand also may discover bugs which occur under unusual inputs which thedeveloper may overlook.In teams of four, you will implement a fuzzer capable of finding bugs inreal life programs. Each team may implement their fuzzer in the program-ming language(s) of their choice.1As part of the project, we have introduceda number of vulnerabilities into a program which we will provide to you as abinary executable. You can use your fuzzer to uncover some of these bugs.At the end of the project, each team will submit a list of the ones they found,and the number of distinct bugs found in the test program will form partof each team’s grade. Not all of the bugs will be equally easy to discover,1We only require that your code compile and run (or just run if it is written inan interpreted language) on the department’s instructional Linux machines, specifically,ilinux{1,2,3}.eecs.berkeley.edu. So in particular C, C++, Java, Python, Perl, and Ruby,are all fine. If your team has a strong desire to write your project in a language for whicha compiler or interpreter is not available on the instructional Linux machines, let us knowand we will try to accommodate you.1however. Whether or not you discover some of the more subtle bugs maydepend on the sophistication of your fuzzer design.The fuzzer implemented by each team will be run from the commandline and will be given arguments which specify how it should invoke anotherprogram which is to be tested. The programs it tests may or may not begraphical, it is only necessary that the fuzzer can start them up from thecommand line. Each generated input will be a either a file to be read bythe program under evaluation, or a string to be given as an argument to theprogram.2 Project Requirements2.1 Modes of OperationThe design of the fuzzer will be based around two modes of operation: searchmode and replay mode.In search mode, the fuzzer will repeatedly invoke the program being testedwith a series of inputs, each time checking to see if the program crashes orif it runs longer than some specified timeout (indicating a possible infiniteloop). Note that it is not considered a bug for the program under evaluationto print an error message or immediately exit. In general, many of its inputswill be invalid in some way, so in those cases such behavior is appropriate.We are only concerned with discovering inputs which cause the program tocrash, which should not happen under any circumstances. For our purposes,we will a consider a program to have crashed if it exited due to signal 11(SEGV).Various strategies for generating sequences of inputs are possible, fromexhausting all possibilities of some short length to producing strings of bytescompletely at random. In most cases though, at least some aspects of eachinput will be selected randomly. When the fuzzer is operating in search mode,it must ensure that, when making any random choices in constructing a par-ticular input, those choices are based on a pseudorandom number generator(PRNG) for which it has saved the seed. If it is determined that a particularinput caused the test program to crash, the fuzzer will then output that seedfor use in replay mode.In replay mode, the fuzzer will take as an additional argument a seedthat it produced while running in search mode. Using that value to seed the2PRNG, it will then reproduce and output for reference the exact input thatpreviously caused the test program to crash.2.2 Search ModeWhen run in search mode, the fuzzer will have the following interface.fuzzer [OPTION ...] CMD [CMDARG ...]Invoked in this way, the fuzzer will run CMD with any listed arguments(CMDARG). For example,fuzzer echo foowould cause the fuzzer to repeatedly run echo foo, checking each time tosee if it crashes.To specify that the fuzzer should construct an input file for the testprogram, a special argument --fuzz-file SPEC will be given among theCMDARG’s. In that case, the fuzzer should generate a file with contents deter-mined by the SPEC argument, and replace --fuzz-file SPEC with the nameof the file when running the command. For example,fuzzer firefox --fuzz-file html-filewill cause the fuzzer to generate a file filled with html data with some name,e.g., test.html, then execute firefox test.html. Similarly, if the specialargument --fuzz-string SPEC is given, a string will be generated accordingto SPEC and passed in place of that argument to the program.The interpretation of the SPEC arguments is left up to your design. Sinceyou will want your fuzzer to test different types of programs and possibly testthe same program using different strategies for generating inputs, you willneed to specify parameters for generating inputs when invoking the fuzzer.The SPEC argument provides a means of doing this. For example, you mightdesign your fuzzer to be able to generate inputs suitable for testing firefox,mplayer (a video player), and grep, in which case you would use the SPECargument to distinguish these cases:fuzzer firefox --fuzz-file html-filefuzzer mplayer --fuzz-file avi-filefuzzer grep --fuzz-string regex --fuzz-file text-file3If after some number of trials in the third example grep crashes with asegmentation fault, the fuzzer should then print the corresponding seed asstring (e.g., 24cdb33d7e3d99cb) on a single line with no spaces on standardoutput. Note that you will probably want your fuzzer to remove generatedinput files after each test so they do not accumulate.2.3 Replay ModeWhen the argument --replay SEED is given as an option appearing beforethe name of the command to be run, the fuzzer will operate in replay mode.In this case, it should seed its PRNG with the seed SEED, then produce inputfiles and input strings as it normally would. At that point, it should printthe
View Full Document
Unlocking...