Microsoft explains how it missed a serious IE bug for NINE years or, as the company chooses to title this blog post, MS08-078 and the SDL:
Every bug is an opportunity to learn, and the security update that fixed the data binding bug that affected Internet Explorer users is no exception.
The bug was an invalid pointer dereference in MSHTML.DLL when the code handles data binding. It's important to point out that there is no heap corruption and there is no heap-based buffer overrun!
Memory-related TOCTOU bugs are hard to find through code review; we teach TOCTOU issues, and we teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues. We will update our training to address this.
Our static analysis tools don't find this because the tools would need to understand the re-entrant nature of the code.
In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code.
Even though Windows Vista and Windows Server 2008 have both ASLR and NX enabled by default, Internet Explorer 7 does not opt-in to these defenses owing to compatibility issues with many common applications. Internet Explorer 8 enables these defenses by default.
On Windows Vista and Windows Server 2008, this is a major defense that comes into play against the currently circulating exploits. When the exploit code runs, it's running at low integrity because IE runs at low integrity, and this means the exploit code cannot write to higher integrity portions of the operating system, which is just about everywhere!
For our server platforms, Windows Server 2003 and Windows Server 2008, Internet Explorer Enhanced Security Configuration also prevents the exploit from working because the vulnerable code is disabled.
How was the bug found?
We really don't know how the bug was found, but some of the security people in Internet Explorer and the Trustworthy Computing Security teams suggest that the bug was either "stumbled upon" or found through directed fuzzing. The finder could spend as long as he or she wanted to find this one bug. This is one of the things that makes security hard - security is a highly asymmetric problem: software developers must get the code right 100% of the time in a very short amount of time, while attackers can spend as long as they want to find one bug. This isn't an excuse; it's a fact of life.
As you can see from this post, many defenses in Windows did not come into play, but all it takes is one defense to help stop or reduce the chance that an exploit will succeed, and in the case of Windows Vista and Windows Server 2008, Internet Explorer's Protected Mode was that defense.
So I’m going to call this the Barbie defense (as in, “math is hard!”). Maybe it will catch on. :)