Redmond security guru explains IE vuln miss
The one that got away
A Microsoft insider has posted an explanation for the firm's failure to spot a critical flaw in Internet Explorer that obliged the firm to publish an out-of-sequence patch earlier this month.
Michael Howard, a principal security program manager with the software giant, explains that the flaw cropped up in a blind-spot developers weren't trained to scour for potential flaws. Human error is always a factor in developing secure code and sometimes fuzzing tools can help unearth error. Unfortunately, in this case, testing tools weren't up to the job either.
Howard explained that the flaw involved a "time-of-check-time-of-use" bug in how Internet Explorer handles data binding objects. "Memory-related [time-of-check-time-of-use, or TOCTOU] bugs are hard to find through code review," Howard writes in a post  to Microsoft's Security Development Lifecycle blog. "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."
Automated tools that throw a range of tests data at applications in order to look for problems also came unstuck, he adds.
"In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code. Triggering the bug would require a fuzzing tool that builds data streams with multiple data binding constructs with the same identifier. Random (or dumb) fuzzing payloads of this data type would probably not trigger the bug, however."
Microsoft's security testers plan to update their testing methodology in order to look more closely for the class of vulnerability exploited by the recent IE flaw. Howard's technically literate post goes on to explain how defences built into Vista and Server 2008 mitigated against the bug. The post, which provides coding examples, illustrates the inherent problems of security testing, an issue developers well away from Redmond are obliged to grapple with every day. ®