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];
}