After the Month of Browser Bugs ended in August 2006, I imagined that browser fuzzing will be over soon. The widespread awareness of this technique and the release of multiple HTML and ActiveX fuzzers were going to help eradicate all easily-found bugs. Vendors were going to incorporate fuzzing in their QA process, and I expected that running a fuzzer in 2007 would be pointless.
It turns out that I was wrong. After the release of Vista, I ran a very simple ActiveX fuzzer against it and only a few minutes later I hit a NULL pointer dereference bug in Internet Explorer. You can read the full advisory at our security research site.
The ActiveX fuzzer I used was extremely simple - it instantiated each available ActiveX control and accessed all its properties. It didn't even have to send any malformed data or long strings, just accessing the ActiveX object was enough to crash the browser. Something this simple isn't supposed to work!
I agree with Microsoft's assessment of the bug as something that's probably not worth fixing in a security update, but the fact stands: this is a bug that should have been found and fixed very early in the development cycle. Maybe next time they'll do better.
It turns out that I was wrong. After the release of Vista, I ran a very simple ActiveX fuzzer against it and only a few minutes later I hit a NULL pointer dereference bug in Internet Explorer. You can read the full advisory at our security research site.
The ActiveX fuzzer I used was extremely simple - it instantiated each available ActiveX control and accessed all its properties. It didn't even have to send any malformed data or long strings, just accessing the ActiveX object was enough to crash the browser. Something this simple isn't supposed to work!
I agree with Microsoft's assessment of the bug as something that's probably not worth fixing in a security update, but the fact stands: this is a bug that should have been found and fixed very early in the development cycle. Maybe next time they'll do better.
I certainly applaud the efforts that Microsoft has made in improving the security in Windows. I don't know the other vendors well, but they're ahead of most other ISVs.
However, to think that means there won't be vulnerabilities in Vista is sort of silly. Simply stated, new or changed code means that there will be new vulnerabilities given the state of art of application security testing today.
For example, we just started a new initiative on our website today with a zero-day page where we record significant zero-day vulnerabilities that may be of interest to our customer base. We recently reported 5 such vulnerabilities to Microsoft in Vista.
I wonder what 2007 will bring. 2006 saw a significant increase in 0-days with IE being openly vulnerable for 284 days during the year as documented by Brian Krebs, and lots of Office 0-days that seemed timed to come just after 'Patch Tuesdays'.
However, to think that means there won't be vulnerabilities in Vista is sort of silly. Simply stated, new or changed code means that there will be new vulnerabilities given the state of art of application security testing today.
For example, we just started a new initiative on our website today with a zero-day page where we record significant zero-day vulnerabilities that may be of interest to our customer base. We recently reported 5 such vulnerabilities to Microsoft in Vista.
I wonder what 2007 will bring. 2006 saw a significant increase in 0-days with IE being openly vulnerable for 284 days during the year as documented by Brian Krebs, and lots of Office 0-days that seemed timed to come just after 'Patch Tuesdays'.