File and protocol attacks
We explain how file or protocol fuzzing leads to direct improvements in code quality. You'll also learn more about available open source fuzzing tools.
When I started out in computers a long time ago, I remember you could open files (images, documents, you name it) without having to worry about viruses because, well, everyone knew you could only get viruses from executable files like .exe, .bat, and .com in the Windows world. In the Linux world, if you could actually get your email client to run an executable attached to an email automatically, you probably had the good sense not to. I remember laughing at someone who asked if they had to worry about getting a virus from looking at images sent to them via email. The times, they have changed.
File-based attacks are now commonplace; at the time of this writing, a PDF-based exploit had become public, and Adobe had announced that they would fix it – in about two weeks. In the meantime you can … uhh … not read any PDF files, I guess, if you use Adobe Reader to view files. Luckily, most Linux users do not use Adobe Reader to view PDF's, but many will have Adobe Flash installed (exploitable via SWF files before Flash Player 10.0.12.36 for Linux), or OpenOffice (EMF and WMF files before OpenOffice 2.4.2). The list goes on and on: image files, font files, web pages, you name it. Many major applications have at some point failed to parse the files properly that they were designed to handle, allowing attackers to create files that can execute arbitrary code when opened.
How Fuzzing Works
The basic premise of file or protocol fuzzing is you subtly (or not so subtly) create input that is malformed. This can be done by such methods as simply flipping random bits in a file or protocol stream to creating a full-featured program or test suite that knows how to generate valid (and thus invalid) files or input for various protocols. An excellent example of a file fuzzer is Michael Zalewski's mangleme CGI program. If you install this CGI program on a web server and a client web browser connects to it, the mangle.cgi script creates a randomly generated HTML file that includes a META REFRESH tag, causing the web browser to reload the script (and get a different randomly generated HTML page). This lets you point a web browser at the URL with the mangle.cgi script and wait for the browser to crash (which it will, eventually, in most cases). The use of META REFRESH addresses one of the biggest problems with fuzzing files: getting a program to load a series of files one after the other in an automated fashion so that a human being doesn't have to sit there opening files.
This leads to some interesting problems and opportunities when fuzzing. On the one hand, you can very quickly and very cheaply run a program against a battery of tests: Leave a browser pointed at mangleme for a few days and it will go through several tens of thousands of test cases. Each request generates a log entry with the identifying number of the test case, which allows you to reproduce the problem. Given this, however, it can still be difficult to reproduce or verify results in some cases. For example, with Internet Explorer version 7.0.5730.13, the mangleme test case 0x6dc61276 doesn't appear to have any effect, except on one machine on which I have PowerDVD 6.0 installed, in which case it will reliably crash Internet Explorer and create an empty file called su0.mpg on the desktop without any prompting. This shotgun approach to security testing is not terribly accurate, but, much like blasting away with a shotgun in a forest, you will eventually hit something of interest (it just might not be what you're looking for).
Random fuzzing presents several problems. For example, you are unlikely to find certain boundary conditions by simply trying random junk; integer overflows and underflows are a common problem, but to trigger them you need to mangle a file or protocol traffic in a specific manner. Many programs use C's signed long int (which supports values from -2147483647 to 2147483647) to specify the length of data fields and so on. This leads to several interesting values: 0x7fffffff, which is 2147483647 (the maximum), and 0x80000000, which is -2147483648 (the minimum value that can be stored). If the program does not properly calculate values, you can end up with a situation in which adding two positive numbers together results in a negative number or adding a negative number to another number results in an even larger number. If these values are used to allocate memory for storing user-supplied data, then a classic buffer or stack overflow is the typical result, and these often are exploitable and can allow for arbitrary code execution.
Write Once, Run a Million Times
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?