Tomorrow starts is the start of the second class, hopefully it will be just as fun as the first.

Thanks to everyone who signed up!

See this mail list post to correct the problem.

The following article will walk you through an example file fuzzer.

Fuzzing file formats passed to applications on the command line have the following flow for each test iteration:

1. Create some mutated data
2. Write the data to disk
3. Launch the application
4. Close the application

To detect faults we will use Microsoft’s Application Verifier application which is able to automatically attached a debugger and set variouse memory debugging options on all processes with a specific executable name.  This is perfect for us since we will be restarting the application for each test we perform.  Peach includes a monitor called “debugger.WindowsAppVerifier” that we will use to control this tool.

Okay, so next up we need to be able to perform steps 2-4.  We will use a publisher called “file.FileWriterLauncherGui”.  This publisher will act as both a stream and call based publisher allowing us to write out a file and then launch an application.  It will wait about 5 seconds and than send a WM_CLOSE message to the application, and finally if the application does not shut down will terminate it.  If we are lucky, the WM_CLOSE message will let the application shutdown normally allowing for additional code coverage.

On with the XML!

Data Model

Nothing very interesting here.  We will have two data models, one will specify the filename for the program (this will make more sense later).  Note that one side affect of requiring the FileName data model will be some fuzzing of the filename.  There are a few mutators (the data tree set) that will not notice the “isStatic” and perform some mutations anyways.

<!-- Define our file format DDL -->
<DataModel name="FileData">
	<String value="Hello World!" />
</DataModel>

<!-- A template to hold the filename -->
<DataModel name="FileName">
	<String isStatic="true" value="fuzzedfile.txt" />
</DataModel>

State Model

Now things get more interesting.  This is were we will define steps 2-4.  There are three actions in the following state model.  The first two will create, write, and close the file after writing out data model out to it.  The third action will launch our application passing as a parameter the FileName data model (fuzzedfile.txt).

<StateModel name="State" initialState="Initial">
    <State name="Initial">
        <!-- Write out contents of file -->
        <Action name=”WriteFile” type=”output”>
            <DataModel ref=”FileData” />
        </Action>

        <!– Close file –>
        <Action type=”close” />

        <!– Launch the file consumer –>
        <Action type=”call” method=”c:\windows\system32\notepad.exe”>
            <Param type=”in” name=”filename”>
                <DataModel ref=”FileName”/>
            </Param>
        </Action>
    </State>
</StateModel>

Agent Configuration

Next up we need to configure out agent and monitor to use the debugger.WindowsAppVerifier monitor.  Notice that the parameter to the monitor specified just the executable name, not the full path.

<!-- Setup a local agent that will monitor for faults -->
<Agent name="LocalAgent" location="http://127.0.0.1:9000">
    <!-- For file fuzzing were the application will be launched and closed
        a number of times we will use Microsofts Application Verifier to
        monitor the process for faults.  -->
    <Monitor class="debugger.WindowsAppVerifier">
        <Param name=”Application” value=”notepad.exe” />
    </Monitor>
</Agent>

Test and Run Configuration

Almost done now, this is the final section were we configure the test and run.  These two sections will tie all these things together and associate our publisher.  I have bolded the two parameters for the publisher we are using.  The filename must match the one in our FileName data model or things will not work right.  Additionally the windowName parameter should be a unique (but partial) application window title.

<Test name="TheTest">
    <Agent ref="LocalAgent" />

    <StateModel ref="State"/>

    <!-- Configure our publisher with correct filename to write too -->
    <Publisher class="file.FileWriterLauncherGui">
        <Param name=”fileName” value=”fuzzedfile.txt” />
        <Param name=”windowName” value=”Notepad” />
    </Publisher>
</Test>

<Run name=”DefaultRun”>
    <Test ref=”TheTest” />
    <Logger class=”logger.Filesystem”>
        <Param name=”path” value=”c:\peach\logtest” />
    </Logger>
</Run>

Running the Fuzzer

Okay, to run this bad boy we will need to launch two command windows.  In one kick off a Peach Agent by running “peach.py -a”.  In the second window we will run our fuzzer by saying “peach.py FileFuzzerGui.xml”.  If all works well you will see notepad popup with “Hello World!” for a few seconds than go away only to be replaced with another notepad window.  If you continue watching you will see “Hello World!” start to get mutated.

The Complete File Listing

Here is the complete file listing for this fuzzer example.  I hope it made sense!

<?xml version="1.0" encoding="utf-8"?>
<Peach xmlns="http://phed.org/2008/Peach" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://phed.org/2008/Peach ../peach.xsd" version="1.0"
	author="Michael Eddington">

	<!-- Import defaults for Peach instance -->
	<Include ns="default" src="file:defaults.xml" />
	<Include ns="pt" src="file:PeachTypes.xml" />

	<!-- Define our file format DDL -->
	<DataModel name="FileData">
		<String value="Hello World!" />
	</DataModel>

	<!-- A template to hold the filename -->
	<DataModel name="FileName">
		<String isStatic="true" value="fuzzedfile.txt" />
	</DataModel>

	<!-- Define a simple state machine that will write the file and
		then launch a program using the FileWriterLauncher publisher -->
	<StateModel name="State" initialState="Initial">
		<State name="Initial">
			<!-- Write out contents of file -->
			<Action name="WriteFile" type="output">
				<DataModel ref="FileData" />
			</Action>

			<!-- Close file -->
			<Action type="close" />

			<!-- Launch the file consumer -->
			<Action type="call" method="c:\windows\system32\notepad.exe">
				<Param type="in" name="filename">
					<DataModel ref="FileName"/>
				</Param>
			</Action>
		</State>
	</StateModel>

	<!-- Setup a local agent that will monitor for faults -->
	<Agent name="LocalAgent" location="http://127.0.0.1:9000">
		<!-- For file fuzzing were the application will be launched and closed
			a number of times we will use Microsofts Application Verifier to
			monitor the process for faults.  -->
		<Monitor class="debugger.WindowsAppVerifier">
			<Param name="Application" value="notepad.exe" />
		</Monitor>
	</Agent>

	<Test name="TheTest">
		<Agent ref="LocalAgent" />

		<StateModel ref="State"/>

		<!-- Configure our publisher with correct filename to write too -->
		<Publisher class="file.FileWriterLauncherGui">
			<Param name="fileName" value="fuzzedfile.txt" />
			<Param name="windowName" value="Notepad" />
		</Publisher>
	</Test>

	<Run name="DefaultRun">
		<Test ref="TheTest" />
		<Logger class="logger.Filesystem">
			<Param name="path" value="c:\peach\logtest" />
		</Logger>
	</Run>

</Peach>
<!-- end -->

Peach 2.1 BETA3 includes the following fixups out of the box:

• checksums.Crc32Fixup — This fixup computes the standard CRC32 as defined by ISO 3309 and is used by PNG, zip, etc.
• checksums.EthernetChecksumFixup — Computes the ethernet checksum.
• checksums.IcmpChecksumFixup — Computes the ICMP packet checksum.

Using Fixups

Our example will be a PNG chunk data model which looks like this:

<DataModel name=”Chunk”>
    <Number name=”Length” size=”32″ endian=”network” signed=”false”>
        <Relation type=”size” of=”Core.Data”/>
    </Number>
    <String name=”Type” length=”4″/>
    <Blob name=”Data” value=”"/>
    <Number name=”CRC” size=”32″ signed=”false” endian=”network” isStatic=”true” value=”9999″ />
</DataModel>

From the PNG spec we know the CRC should be of Type and Data.  We will need to do two modifications to this data model.  First we will need to wrap Type and Data in a Block element.  Second we will add our fixup.

<DataModel name=”Chunk”>
    <Number name=”Length” size=”32″ endian=”network” signed=”false”>
        <Relation type=”size” of=”Core.Data”/>
    </Number>
    <Block name=”Core”>
        <String name=”Type” length=”4″/>
        <Blob name=”Data” value=”"/>
    </Block>
    <Number name=”CRC” size=”32″ signed=”false” endian=”network” isStatic=”true” value=”9999″>
        <Fixup class=”checksums.Crc32Fixup”>
            <Param name=”ref” value=”Core”/>
        </Fixup>
    </Number>
</DataModel>

The bolded portions are the changes we made.  The one of most interest is the <Fixup> element that is a child of the CRC number.  All fixups take a single parameter of ref that specifies the name of the element that we will operate on.  In this case that is Core the wrapper of Length and Data.

Creating Custom Fixups

Creating custom fixups are easy and require implementing a single class and two methods.  The following is the code for the Crc32Fixup that we used in the above example:

class Crc32Fixup(Fixup):
	'''
	Standard CRC32 as defined by ISO 3309.  Used by PNG, zip, etc.
	'''

	def __init__(self, ref):
		Fixup.__init__(self)
		self.ref = ref

	def fixup(self):
		stuff = self._findDataElementByName(self.ref).getValue()
		if stuff == None:
			raise Exception("Error: Crc32Fixup was unable to locate [%s]” % self.ref)

		return zlib.crc32(stuff)

To implement your own Fixup simply copy this code and change the class name (Crc33Fixup), the Exception string and finally implement your own fixup code instead of “return zlib.crc32″.  To include your custom module see the documentation about <PythonPath> and <Import> in the Peach 2 Tutorial.

Thanks to David for reporting this bug.

Patch and List Post

First up lets take a look at the default mutators included with this release:

default.NullMutator

The first mutator we will look at is the NullMutator.  This mutator has a single test case that does not modify anything.  By default this is the first mutator Peach will use so the first iteration (#1) will produce data that was not modified in anyway to help with debugging of your fuzzer.

string.StringTokenMutator

Next up is the StringTokenMutator.  This mutator is applied to all string elements in a data model.  This mutator will tokenize the strings default value (if any) and perform a number of mutations on the resulting token tree including 1,000 to 2,000 bad strings, removals, additions, duplications, etc.  The string “?key1=value1&key2=value2″ will result in about 40,000 test cases from this mutator.

string.XmlW3CMutator

The XmlW3CMutator will cycle through every XML test case provided by the W3C.  This numerous XML files that have caused faults in various XML parsers.  This mutator will only target string elements that have a hint of type=xml.

string.PathMutator

As one would guess this mutator performs mutations on file system paths including UNC network paths.  In the current beta3 release this mutator is fairly limited but will be expanded for the non-beta 2.1 release.  Additionally, this mutator will only target strings that have a hint of type=path.

string.HostnameMutator

You would also be correct in assuming this mutator performed mutations of hostname.  Again, the mustations performed will be expanded for the 2.1 release, but still currently useful.  This mutator will only target strings that have a hint of type=hostname.

string.FilenameMutator

Finally, I bet you can guess what this mutator does!  That’s right, mutates filenames and filenames that include paths.  This mutator will only target strings that have a hint of type=filename.

number.NumericalEdgeCaseMutator

The NumericalEdgeCaseMutator targets all Number elements in the data model and cycles through a number of interesting numerical edge cases which occur on type boundaries (0, min/max for both signed/unsigned).  Currently we will go from Edge Number - 50 through Edge Number + 50.  This mutator is good at locating certain types of integer overflow related faults.

number.NumericalVarianceMutator

The NumericalVarianceMutator also targets all Number elements in the data model.  This mutator will take the default value and generate a range of values starting with Default Value - 50 through Default Value + 50.

number.FiniteRandomNumbersMutator

This mutator will produce upto 5,000 random numbers between the min/max of a Number element.  This mutator is useful for triggering unpredictable faults.

blob.BitFlipperMutator

This release also includes a simple bit flipper that targets Blob elements in the data model and performs random bit flips based on the size of the blob.  For example the larger the blob the more flips will occur.  This mutator is finite.

datatree.DataTreeRemoveMutator

This mutator will walk our data model and remove nodes one at a time.

datatree.DataTreeDuplicateMutator

Similar to the DataTreeRemoverMutator accept this mutator will walk the data model and duplicate nodes from 2 through 50 duplications of each node.

datatree.DataTreeSwapNearNodesMutator

Finally, the last mutator included with Peach 2.1 will swap sibling nodes in the data model causing the data model to be reagranged.

<DataModel name="FilenameParameter">
  <String name="Filename" value="c:\path\file.bin" />
</DataModel>

The Filename string element is a prime candidate for a hint indicating that not only is it a string, it is also a filename.  The following is our changed data model that includes a hint:

<DataModel name="FilenameParameter">
  <String name="Filename" value="c:\path\file.bin">
    <Hint name="type" value="filename" />
  </String>
</DataModel>

Multiple Hints are allowed per data element.  The current set of mutators included with Peach only understand the following hints:

This new beta includes a lot of changes and makes Peach feature complete for the 2.1 release coming in the next month or so.  Many of the changes were internal clean ups.  The internal DOM is now much cleaner and easier to use, as is the API to the engine and parser.  Additionally, this release include a new GUI application called Peach Validation.  This application allows testing of your data model and also mutators.  A screen shot has been included.

Additional features include Hints, Fixups, new “calc” length types, ability to specify a file to Data elements, etc.  To much to talk about in this post.  However, keep an eye on this blog for additional articles over the next few days exploring the new features of Peach 2.1 BETA3.

Peach

Peach Release Notes

Peach Downloads

I originally wrote Peach 1 at ph-neutral 4 or 5 years ago, so it seemed fitting to come back and talk about Peach 2.  I had a blast and look forward to next year.

ph-neutral

First off, what is the unsafe keyword and how can it be used?  Glad you asked, unsafe allows for the use of pointers in .NET code.  This includes pointers to managed objects such as arrays and strings.  To use the unsafe keyword the assembly or executable must be compiled with a special flag allowing for unsafe code blocks.  The resulting assembly/executable will not be verifiable by the CLR.

Modification of Immutable Types

With power comes the temptation to modify immutable types such as strings.  Resist this urge as the CLR does a number of internal optimizations for known immutable types like strings.  Modification of these immutable types can and will cause instability in the CLR, and have interesting ramifications.  For example, some versions of the CLR keep only a single copy of strings.  So if I created three strings, all with the value "Hello World", I would really only have three references to the same string.  This is okay since the string object is immutable.  However, if I take a pointer to the string and change its contents I will end up changing the contents of all three strings!!

Managed Pointers and Pinning

The .NET memory manager can move values and object instances around in memory as needed.  So, if we are going to get a pointer to such a memory region we need to tell the memory manager not to move that memory on us.  Enter object pinning.  Pinning tells the CLR not to move something until it is unpinned.  A typical bug in unsafe code is when a managed pointer is held on to and used after it’s reference has been unpinned.  This is a hard bug to detect as the program may run fine most of time and the crashes that occur may not be obviously linked to the unsafe code.

In the C# managed language, pinning typically occurs using the "fixed" block.  This makes it easier to spot issues.  I recommend avoiding other methods of pinning variables as they can be harder to review.

The managed extensions to C++ also provide what feels like "lower level" control over variable pinning.  This is typically harder to review, but then if you are writing in MC++ you should already know what your about :)

Buffer Overflows and other Pointer Issues

With the unsafe keyword and pointer math come all the standard security issues those C/C++ developers need to worry about.  There is a real possibility of causing buffer overflows that result in exploitable conditions in .NET applications.  Buffer manipulation should be reviewed just like C/C++ for possible overflows.

And so ends part 1 of this article.  Please feel free to comment on this post with questions and comments.