Project Description CS161 Computer Security Spring 2008 1 Overview The goal of this project is to implement a fuzzer or fuzz tester Fuzz testing is one way of attempting to discover security vulnerabilities in code implementing a network protocol or otherwise processing potentially malicious input The concept of a fuzzer is simple it repeatedly runs a program which is being evaluated on a series of automatically generated inputs If some input causes the program being tested to crash with a memory access violation the program has failed the test and may have an exploitable security vulnerability By generating inputs either partly or completely randomly the fuzzer can rapidly run large numbers of tests without human supervision and also may discover bugs which occur under unusual inputs which the developer may overlook In teams of four you will implement a fuzzer capable of finding bugs in real life programs Each team may implement their fuzzer in the programming language s of their choice 1 As part of the project we have introduced a number of vulnerabilities into a program which we will provide to you as a binary 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 part of each team s grade Not all of the bugs will be equally easy to discover 1 We only require that your code compile and run or just run if it is written in an 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 which a compiler or interpreter is not available on the instructional Linux machines let us know and we will try to accommodate you 1 however Whether or not you discover some of the more subtle bugs may depend on the sophistication of your fuzzer design The fuzzer implemented by each team will be run from the command line and will be given arguments which specify how it should invoke another program which is to be tested The programs it tests may or may not be graphical it is only necessary that the fuzzer can start them up from the command line Each generated input will be a either a file to be read by the program under evaluation or a string to be given as an argument to the program 2 2 1 Project Requirements Modes of Operation The design of the fuzzer will be based around two modes of operation search mode and replay mode In search mode the fuzzer will repeatedly invoke the program being tested with a series of inputs each time checking to see if the program crashes or if it runs longer than some specified timeout indicating a possible infinite loop Note that it is not considered a bug for the program under evaluation to print an error message or immediately exit In general many of its inputs will be invalid in some way so in those cases such behavior is appropriate We are only concerned with discovering inputs which cause the program to crash 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 from exhausting all possibilities of some short length to producing strings of bytes completely at random In most cases though at least some aspects of each input will be selected randomly When the fuzzer is operating in search mode it must ensure that when making any random choices in constructing a particular input those choices are based on a pseudorandom number generator PRNG for which it has saved the seed If it is determined that a particular input caused the test program to crash the fuzzer will then output that seed for use in replay mode In replay mode the fuzzer will take as an additional argument a seed that it produced while running in search mode Using that value to seed the 2 PRNG it will then reproduce and output for reference the exact input that previously caused the test program to crash 2 2 Search Mode When 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 foo would cause the fuzzer to repeatedly run echo foo checking each time to see if it crashes To specify that the fuzzer should construct an input file for the test program a special argument fuzz file SPEC will be given among the CMDARG s In that case the fuzzer should generate a file with contents determined by the SPEC argument and replace fuzz file SPEC with the name of the file when running the command For example fuzzer firefox fuzz file html file will 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 special argument fuzz string SPEC is given a string will be generated according to SPEC and passed in place of that argument to the program The interpretation of the SPEC arguments is left up to your design Since you will want your fuzzer to test different types of programs and possibly test the same program using different strategies for generating inputs you will need to specify parameters for generating inputs when invoking the fuzzer The SPEC argument provides a means of doing this For example you might design 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 SPEC argument to distinguish these cases fuzzer firefox fuzz file html file fuzzer mplayer fuzz file avi file fuzzer grep fuzz string regex fuzz file text file 3 If after some number of trials in the third example grep crashes with a segmentation fault the fuzzer should then print the corresponding seed as string e g 24cdb33d7e3d99cb on a single line with no spaces on standard output Note that you will probably want your fuzzer to remove generated input files after each test so they do not accumulate 2 3 Replay Mode When the argument replay SEED is given as an option appearing before the 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 input files and input strings as it normally would At that point it should print the command line it would have executed then exit For example fuzzer
View Full Document
Unlocking...