April 27th, 2007

Microsoft mulling major changes to ward off .ANI-type flaws

Posted by Ryan Naraine @ 9:38 am

Categories: Botnets, Browsers, Data theft, Exploit code, Firefox, Hackers, Metasploit, Microsoft, Patch Watch, Pen testing, Responsible disclosure, Rootkits, Spam and Phishing, Spyware and Adware, Viruses and Worms, Vulnerability research, Windows Vista, Zero-day attacks

Tags: Security, Flaw, Compiler, Microsoft Windows Vista, Microsoft Windows, Microsoft Corp., Mitigation, Tool, Attack, Ryan Naraine

How did the super-critical animated cursor (.ani) vulnerability get past all the strict code review, fuzz testing and other defense-in-depth mitigations built into Windows Vista?

Michael Howard (left) has the answer and he's sharing it with us in a candid explanation from Microsoft on the lessons learned from the recent zero-day attacks and some planned changes to fix some warts in the SDL (Security Development Lifecycle). 

[NOTE: The SDL is a mandatory software creation process used at Microsoft to reduce the number of security-related design and coding defects, and to reduce the severity of any defects inherited from legacy code].

Howard, who co-wrote a book that explains the intricacies of the SDL, has dropped some broad hints at some of the changes that will be made to the SDL to ward off .ani-type flaws, including a possible addition to the list of banned API function calls, more aggressive checks for buffer overruns and enhancements to existing fuzz testing tools.

The changes are in keeping with the ever-evolving nature of the SDL, which is constantly updated to respond to new vulnerability discoveries and malware attacks.

During the creation of Windows Vista, more than 140,000 unsafe API calls were banned and Howard hinted that one more — "memcpy" — might be added to the list for new code coming out of Redmond.

He also offered detailed technical explanations for the defense-in-depth measures that did not stop the .ani threat, including /GS, a component that detects some buffer overruns. Howard said Microsoft will "rethink the heuristics" used by the /GS compiler to flag certain issues. "Changing the compiler is a long-term task. In the short-term, we have a new compiler pragma that forces the compiler to be much more aggressive, and we will start using this pragma on new code," he added.

Two other Windows Vista security mechanisms — ASLR and SafeSEH — were also in place to catch code failures but, in the case of the .ani bug, Howard said the attackers were able to wrap vulnerable code in an exception handler to find ways around those mitigations.

We're investigating this issue further to determine ways of finding exception handlers that may wrap potentially vulnerable code.

A big part of the SDL is the use of static analysis and fuzz testing tools to local potential vulnerabilities but Howard said the tools did not flag this as a security bug because the "memcpy" call 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. Another angle is to replace calls to memcpy with memcpy_s which forces the developer to think about the destination buffer size. We may ban memcpy for new code, but we still need to analyze this further. Stay tuned.

Howard made it clear that the animated cursor code was fuzz-tested extensively but, because none of the .ani fuzz templates had a second "anih" record, the .ani bug escaped discovery. (See Alexander Sotirov's technical explanation on the "anih" chunk and the buffer overflow).

Howard said this weakness has been addressed as part of the continuing enhancing of Microsoft's fuzzing tools "to make sure they add manipulations that duplicate arbitrary object elements better."

One Windows Vista defense-in-depth mitigation that did kick in to reduce the attack surface was UAC and Protected Mode Internet Explorer. These technologies put up a roadblock and limited the damage from the .ani attack but, as Mark Russinovich explained at CanSecWest last week, malware writers can exploits for Vista's standard user default.

""The SDL is not perfect, nor will it ever ever be perfect," Howard argued. "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," he added.