Here’s something you don’t see from Microsoft often — a detailed assessment of how it missed a big security hole. In this case the topic is the much-attacked ANI flaw and how it was allowed into Vista.
Michael Howard, Microsoft’s point man on the Security Development Lifecycle (SDL) — the software giant’s effort to get developers to be more security-minded when writing code — offers up a very detailed assessment of what went wrong in the company’s new Microsoft SDL blog.
Among the problems found:
— A Vista security feature called Address Space Layout Randomization (ASLR) is designed to randomly attach data to memory to stymie attackers who are trying to find the location of critical Windows functions, but it didn’t seem to work in the case of ANI.
“If the vulnerable code is wrapped in an exception handler that catches many errors [as was the animated cursor code], a failed attempt will not crash the component and the attacker can try again with a different set of addresses,” Howard wrote.
— Microsoft testing tools failed to see the trouble with the code, which actually dates back to the aging Windows 2000 OS.
“Our static analysis tools do not flag this construct as a security bug because it’s a very low-priority warning,” Howard wrote. “Why? Code that uses calls such as ‘memcpy’ is hard to flag as vulnerable without generating a great many false positives. This is a research problem that no one has solved, here or elsewhere.”
As for lessons learned on ANI, he wrote, “SDL is not perfect, nor will it ever ever be perfect. We still have work to do, and this bug shows that. We have a new -GS pragma that adds more stack cookies; we’ve updated our fuzz tools; we will pay closer attention to exception handlers that could mask vulnerabilities, and we will investigate the impact of banning memcpy for new code. Finally, we will update our education as necessary with lessons learned from this bug.”