Last updated at Wed, 26 Jul 2017 17:30:32 GMT
In October of 2004, Michal Zalewski posted to the Bugtraq mailing list about his MangleMe utility. This CGI script generated random chunks of malformed HTML and managed to shake out flaws in almost every modern web browser. A few months later, Michal posted about the results of his JPEG fuzzer, which was also able to crash Internet Explorer in a few different ways. A year or so has passed and it was time for a another fuzzer :-)
Inspired by Michal's work, I created a javascript COM fuzzer to locate common flaws in ActiveX controls. After a weekend of tweaking and testing, I compiled a list of nearly 60 flaws in Internet Explorer. With a few exceptions, these flaws were limited to an unexploitable crash, but the sheer number of flaws was amazing. After some digging around, I ran across a public tool called axfuzz that performed a similar set of tests, duplicating many of the crashes identified by my fuzzer. Shane Hird released axfuzz in February of 2005 and even took the time to contact Microsoft about his results. Microsoft's response wasn't very helpful:
"COM objects can be called from an object tag and if they are not actually ActiveX controls they can cause IE to terminate."
Microsoft acknowledges that any Internet web site is allowed to shut down Internet Explorer...and this is OK. Why would they bother fixing any other IE denial of service flaw when they take this approach to COM objects? A good example of this issue is the OutlookExpress.AddressBook component, which is installed by default on most versions of Windows. Creating an instance of this object in IE 6.0 is enough to kill the browser.
Excluding the object instantiation flaws, there were a number of interesting bugs found by the fuzzer. Some objects provide the ability to access an arbitrary item of an internal array, even if that array hasn't been populated, allowing for some odd exploit scenarios (fill the heap to cover where the array should be, work through the list of dereferences). One of the strangest cases was triggered by setting an object property to a static value, over and over again, eventually triggering a pointer overwrite. It seems like even a single dword heap overflow can become exploitable with enough work. Another fun case was a memory corruption bug triggered by freeing a COM object (forced redirect to another page) that had one of its attributes set to an instance of a similar object.
Nearly all of these flaws have been reported to the vendor (with case numbers received) and the COM fuzzer will be made available once the big issues have been patched. If you are impatient, you could always reproduce the crash issues with axfuzz, or try out iDefense's COMRaider tool.
One of the coolest things about exploiting COM bugs via Internet Explorer is that even if you aren't allowed to create a given COM object, the associated libraries are still mapped into the process. If you find a way to control code execution, you can pick your own return address (DLL bounce) by attempting to create a COM object that uses a library which happens to have the opcodes you need at a reliable address. In many cases, this method can used as an alternative to heap filling, especially if you have partial control of the address. Scan the DLL set looking for something with the appropriate IMAGE_BASE address (say, using msfpescan in framework-2.5), figure out what COM objects use that DLL, create a new object, and then trigger your bug :-)
COM and ActiveX is fun, but it is limited to browsers based on Internet Explorer. The next project was to write a DHTML element fuzzer that could test all modern browsers for common implementation flaws. The process was simple - make a list of all known DHTML elements, their properties, their methods, and then beat the crap out of them until something gives. The fuzzer was called hamachi (because lunch was sushi and project names don't need to be unique, damnit), and was uploaded to the metasploit.com web site. The first version received a ton of feedback, usually along the lines of "wow, [some browser] crashed quick!". Aviv Raff contacted me about making some improvements to the code and we have both been adding new techniques since.
Hamachi has found flaws in Firefox 1.0.7, Mozilla 1.7, Konqueror 3.5.1, Opera 8.5, Safari, and Internet Explorer. The vendors have not been officially notified (due to lack of time), but the fuzzer code is public and nothing stops them from sending a link to their QA departments :-)
Considering how many browser bugs are turning up, maybe its time we develop a consistent, reusable API for exploiting browsers. So many exploits are using Skylined's heap spraying technique, we may as well add animated progress bars, DHTML layers, and trance background music to the Metasploit Framework modules :-)
