August 1st, 2005, 12:16 AM
A good way to describe fuzzing is found on SpiDynamics website:
At an abstract level, fuzzing can also be described as "organized chaos". Give a fuzzer a specific set of rules, protocol, or a standard of some sort (or none), and you can create randomized chaos to hopefully create an exception to the rule.
"Fuzzing" is an automated software testing technique that generates and submits random or sequential data to various areas of an application in an attempt to uncover security vulnerabilities. For example, when searching for buffer overflows, a tester can simply generate data of various sizes and send it to one of the application entry points to observe how the application handles it.
A more practical description: When an application comes across a certain situation or data it didn't expect to see, but is programmed to handle anyway, you cause an exception. Whether the exception is handled appropriately or not is where vulnerability comes into question. A fuzzer will output random, unpredictable results, and hope to find a combination or situation that will cause it's target to fail.
This technique is useful in many areas involving any sort of input validation. This tutorial will describe the usage of an application by iDEFENSE which "fuzzes" data into specific file formats, and automates the process of testing the generated files with their respective applications.
FileFuzz is available at:
FileFuzz (FF) has presets for some common files. They can be found in the dropdown menu at the top of the screen. The following are the presets, file extension followed by the software that the filetype will be tested againt:
bkf - ntbkup.exe
cbo - orun32.exe
chm - hh.exe
hlp - winhlp32.exe
ht - winhlp32.exe
jpg - iexplore.exe
pdf - AcroRd32.exe
rm - RealPlay.exe
vcf - OUTLOOK.EXE
wab - wab.exe
wmf - shimgvw.dll
By selecting a preset, you use a sample file provided by FF to fuzz against.
Below, change the radio button from "All bytes" to range, 0-10 as a quick start. You can then hit the create button to start creating files. (The selection "All Bytes" can risk taking up a lot of disc space) You can then see the files created in the default folder (c:\fuzz\filetype\)
What this did is create files that are similar to the sample (source) file, and fuzzing specific areas, such as range 0-10 bytes like we specified. You can see the effects by hex editing the files. The first ten bytes in all of the files output by FF will have different patterns.
Create a file, FuzzMe.hrt, and open it in a text editor. Fill it with the following contents:
We're going to pretend that FuzzMe.hrt is read by another application, and the contents (1111,2222....) will be read and acted upon by the application.
You can specify this as your source file in FF. My example, FuzzMe.hrt, seems to be comma delimeted. If we want to attack a certain field in this file, we can configure FileFuzz to do that.
We're going to attack the first field of FuzzMe.hrt. In the scope box, set the range to 0-3, and check out the output files with a hex editor. You'll see it altered only the first 4 bytes of the file (within the field we wanted to attack). If we change it to 5-8, it would attack the second field, and so on. We can also set what bytes to fill it with, to what length (Buffer Overflows), and if we want to match patterns.
Clicking the box, "Execute" at the top will change FF to it's execution interface. You can specify the software you want to run the fuzzed files under, automating the attack process. You can specify the path of the application you are attacking with your fuzzed files, as well as any necessary arguments need to run the application.
The start and finish file numbers tell FF what fuzzed files it's going to attack the application with. FF will create fuzzed files named 1.ext, 2.ext, 3.ext and so on, so the start / finish section will help you prevent your attack from running too long.
By selecting execute, FF will then run through the fuzzed files and attack the specified application. By detecting exceptions that result, it makes fuzzing attacks much easier.
By reading the standards behind specific file formats, you can specify what parts of an application may be vulnerable. The types of vulnerabilities that could be discovered from a process like this are similar to the following:
Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution (833987)
Vulnerability in Microsoft Color Management Module Could Allow Remote Code Execution (901214)
libtiff STRIPOFFSETS Integer Overflow Vulnerability
Winamp remote buffer overflow vulnerability
Vulnerability in MSN Messenger Could Lead to Remote Code Execution (896597)
The Antivirus Vector
As a personal insight...
The easiest vector into an AV is to let the AV scan a malicious file. Because file formats are getting more complex (zip, rar, encryption, interpretation) it means AV is becoming more complex to handle it (can you say... heuristics?). Where complexity arises, so does vulnerability. File fuzzing gives a direct opportunity to discover exploitable holes in AV heavily in the future.
AV's are popular on mailservers. A simple vector against a mailserver would be to exploit the AV running on it, because it would have to process your attachment. Fuzzing will be a simple research tactic against AV's, maybe not through FileFuzz, but maybe in more advanced applications in the future.
Clam AntiVirus FSG File Processing Overflow
ClamAV Multiple Integer Overflow Vulnerabilities
Thanks, feedback appreciated.