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.
0 komentar:
Posting Komentar