Randomization in SWFz

First of all, SWFz is a static security testing tool (not released, sorry) that is, as the name implies, aware of the Flash file format. Originally, it has been developed to generate test samples for Adobe Flash Player but surely the samples generated by this tool can be used to test any application that parses Flash file.

There are numerous methods embedded in the application to create fuzzed samples. The main reason for this is the demand for different fuzzing opportunities. Additionally, I added methods when parsing of some structures hadn't been completed yet but some ones had. These methods weren't planned but I thought to be a good idea to add them until I finish the relevant code, after all it still provides some creativity in the test cases.

So there are methods being primitive by ignoring some structures and there are methods being much structure aware for targeted testing. Then there are the between methods.

There is one important thing that's same among the methods: the fact of randomization.

As you envisage, SWFz has been evolutionary evolving. Initially, a simple method had been implemented that is dumb fuzzing; I call it fuzzing of linear blocks. The program divides the file into linear blocks, and can overwrite the byte at random position by a random value in each block. That time, I wanted to start with a simple feature and I did it by this. The position of each block and the byte value for altering the original one were chosen by random.

One of the next evolution stage was that the tool is able to locate the position and the size of the methods storing the actionscript bytecodes. Clearly, with this it's possible to launch more targeted fuzzing. The program can overwrite the bytecode at random position by a random value in each method. The position of each method and the byte value for altering the bytecode were chosen by random.

One of the next evolution stage was that the tool is able to locate the position and the size of the methods storing the actionscript bytecodes, moreover it is able to locate the position of each bytecode. The program can overwrite the opcode part of the bytecode at random position by a random opcode defined in a set. Practically, it means the program is able to replace the instruction with an other instruction that has the same size and properties.

I could have used the computer clock to generate the random numbers, that might work, I however have chosen a predictable random generator method called Mersenne twister. Using this, I can safely reproduce the test cases at any time, and the testing of the fuzzer can be done in more straightforward way.

The forensic example

I've been busy with a new project involving data formats. It's my C++ training. In the past, I developed a lot in C, was working on file format parser modules. Now there is something new here. Firstly, it's C++. Secondly, it's about data formats, and data structures. Although it will contain parser modules this is not about parsers.

Let's assume a crime. There is some evidence that is a file fragment. You might think it's hard to imagine but let's just think the file fragment is recovered from a corrupted disk. You need to extract evidence from that file. You need to make the best explanation what is the file for. Where is it from? Who or what did produce it? Maybe the meaning of that file depends on a proprietary application but that is not available and you need to extract as many information as possible to draw conclusion. How would you analyze that binary fragment? You might open it in your hex editor, launch entropy analysis on it, extract the printable strings, look for padding bytes, for possible header fields, for code of IA32 or ARM, or for constant values. That's very nice but doing everything manually it's a bit time consuming, and the murder is still out.

This tool is about analyzing binary objects involving unknown ones, discovering the structure of the object. The forensic example mentioned above is just one; I could have said how important to discover the underlying structure of objects for targeted fuzzing, too.

Fuzzer protocol and handler

There is no fundamentally new thing here I just want to note how a simple solution can be both powerful and flexible.

I test rich media files in browser. Although I could open them directly in the browser using file protocol I rather create wrapper HTML files embedded the rich medias in them and use http protocol. Along with this I have more control over the testing -- I can set properties for the embedded media, can navigate to an other HTML page which contains another rich media, or can just refresh the page, etc...

What if I want more control? I tell an example. If the browser crashes on an altered embedded file of HTML, once the browser relaunched, I need to open the following HTML file to continue testing from the point crash occurred at. So I want to set an environment variable regarding which HTML file is being opened.

I could use script languages embedded in the HTML files. I already use Perl to launch the fuzzer but this time I should set-up the system to run Perl script in the browser. I don't like this much for two reasons. What if I want to run native code in the future? There might be a solution for this but I should code both Perl and some native code. I'm not an expert in script languages it would take time to me to make the things working. So I looked after alternatives.

It seems to be obvious solution to register my program to a URL protocol. I need the .REG file that registers the protocol. I need a tiny change in the HTML file to call the newly developed fuzzer:// protocol with the appropriate token. Last, I need the protocol handler which is the program I want to run when the protocol called from the HTML.

My fuzzer-like application II

In the past weeks, I allowed a bit more time for development of my fuzzer. In spite of the fact it is still not a file format aware one it does very good jobs. It is now working automatically without any user interaction.

I developed a hook module that needs to be injected into the process address space. I use this module to be injected in Firefox process. I set it to hook ReadFile() to fuzz lpBuffer as long as hFile is a handle of any SWF file.

I wrote a Perl script that opens each SWF in Firefox. When any SWF accessed by ReadFile() my fuzzer does its job.

I also wrote a DOS batch script called from the above Perl script. This script is to attach CDB debugger to Firefox to intercept exceptions. If exception occurs it calls !exploitable to analyze exception and saves the logs and data for reproducation to a customized folder.

Results of running of last 12 hours seen below. Number of crashes in the brackets.

PROBABLY_EXPLOITABLE::User Mode Write AV near NULL (2)
UNKNOWN::Read Access Violation (1)
UNKNOWN::Data from Faulting Address controls Branch Selection (82)
UNKNOWN::Data from Faulting Address may be used as a return value (1)

I haven't tried to reproduce all issues due to the lack of time but I both was and wasn't able to reproduce some of crashes. I think I should write a script that will separate the consistently reproduceable issues to being focused on the most important things.

My fuzzer-like application I

One rainy Sunday I, without any intention, decided to make some specially crafted URLs to instantly test against the latest version of Quicktime. I didn't think to have any chance to crash QT using those small amount of URLs, I was just playing as a kid. No crash occurred and I thought it was enough of play so I was about to do some other things and closed QT. In fact, the followings happened: one of my previously entered URL caused a heap buffer overflow which overwrote the metadata of heap somewhere. This didn't trigger any visible effect until I attempted to close the application. Then the Windows attempted to free the memory using the corrupted heap block. This leaded to crash. The vulnerability got a CVE number of CVE-2009-0001.

I was inspired by the recently found vulnerability to start developing a very basic file fuzzer. It didn't appear a file format aware one but had the functionality to fuzz within an offset range of file. I picked up a [Vendor] [File format type] file and created few hundred altered samples using my fuzzer-like application. I set my fuzzer-like application to fuzz the file within a tight range around a file offset. I knew if I press a hotkey inside [Product name] the fuzzed part of file will be immediately accessed, because the hotkey was to update the file. I opened each files with [Product name] and pressed the hotkey inside it to test. It was my luck that an exception was triggered on one of file by the hotkey. I found a memory write access violation, and I found two other ways how to trigger.

A few weeks later, I improved my fuzzer-like application but didn't appear changing in the fuzzing method itself rather it got a new functionality towards automatic test. It got a feature to being able to simulate any keypresses inside applications. I fuzzed some picture format and tested against IrfanView. The test appeared to work very well but no exception encountered. I would say this test was to test the fuzzer-like application instead of IrfanView.

In the next few days, I improved my fuzzer-like application but didn't appear changing in the fuzzing method itself rather it got a new functionality towards automatic test. It got a feature to being able to drop the altered files into a window. I originally wanted this feature to test Internet Explorer and Firefox but it didn't work with them for some reason. I decided to try how Opera like my fuzzer-like application and here is the result. I created a quite a few of altered Flash files and launched the function of my fuzzer-like application to drop altered files onto Opera. It seemed Opera liked my fuzzer-like application. I also got crashes but once I wanted to reproduce them I was unable to do. I realised the crashes occurred after a high number of samples already dropped onto Opera. This kind of test appeared to be inconsistent and I didn't think to do that again. I had to work out another plan to being able to test browsers without such obstacle.

A couple of days later, I again improved my fuzzer-like application but still didn't appear changing in the fuzzing method itself rather it got a new functionality towards automatic test. It got a feature to being able to create HTML files for each altered Flash files. The Flash files were embedded into the HTML files. The HTML files were linked together and when you opened the first HTML file it showed the Flash object then opened the next HTML file which showed the Flash object then opened the next HTML file, and so on.

Firstly, I launched test against IE and it did very well job without any crashes. I also launched this test against FF which crashed in certain circumstances. I was consistently able to reproduce the crashes included on another machine. After it unloaded a DLL of Flash plugin, tried to access to the unloaded object. It was obvious to being exploitable for code execution if I fill the address of unloaded Flash object. On the same day, I developed an exploit and provided with the vendor. The vulnerability has a CVE number of CVE-2009-2467.

This was a short story of my fuzzer-like application. As far as I'm concerned, the above three vulnerabilities are far enough to continue developing my fuzzer-like application to be a real Fuzzer one day.

Bigger memory allocation than expected

Wrong function

void* allocateBytes(size_t size)
{
  if (size > MAX_SIZE)
    return NULL;

  return new void*[size];
}

Fixed function

void* allocateBytes(size_t size)
{
  if (size > MAX_SIZE)
    return (void*)NULL;

  return (void*)new char[size];
}