Microsoft explains how it missed critical IE bug
Developers didn't have proper training or right testing tools, a noted proponent of the company's secure code development process acknowledged
Follow @infoworldMicrosoft Corp.'s developers missed a critical bug in Internet Explorer because they weren't properly trained and didn't have the right testing tools, a noted proponent of the company's secure code development process acknowledged last week.
The bug, which Microsoft patched last week with an emergency update, had gone undetected for at least nine years.
[ Read the earlier developments in the story: "Microsoft fixes IE bug" | Learn how to secure your systems with Roger Grimes' Security Adviser blog and newsletter, both from InfoWorld. ]
In an insider's description on Microsoft's Security Development Lifecycle blog, Michael Howard, a principal security program manager with the company, offered a postmortem analysis of the IE vulnerability and Microsoft's code-writing and reviewing process.
Howard, who is perhaps best known for co-authoring the book "Writing Secure Code," said the flaw was a "time-of-check-time-of-use" bug in how IE releases data binding objects.
The vulnerability was not found by programmers because they had not been told or taught to look for them in such cases, Howard said. "Memory-related [time-of-check-time-of-use, or TOCTOU] bugs are hard to find through code review," he said. "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."
Microsoft's testing tools -- including "fuzzers," automated tools that drop data into applications, file formats or operating system components to see if, and where, they fail -- also missed the bug, Howard admitted.
"In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code," he said. "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."
Howard said that Microsoft would update its developer training to account for memory-related TOCTOU bugs like this one.
Several parts of Windows' security toolkit didn't help protect users from exploits of this bug, Howard added, including ALSR and NX, technologies available only in Windows Vista and Windows Server 2008. "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," Howard noted.









