Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=199202711
A program manager on Microsoft's security team wrote up a post-mortem on the .ANI vulnerability and how the bug worked its way from Windows 2000 all the way up into Windows Vista.
Michael Howard wrote a lengthy explanation in Microsoft's newly hatched Security Development Lifecycle (SDL) blog late last week.
"A core tenet of the SDL is to take and incorporate lessons learned when we issue a security update, and there is a great deal to learn from the recent animated cursor bug," wrote Howard. "SDL is not perfect, nor will it ever be perfect. We still have work to do, and this bug shows that ... we will update our education as necessary with lessons learned from this bug."
The .ANI vulnerability lies in the way Windows handles animated cursor files and could enable a hacker to remotely take control of an infected system. The bug affects all the recent Windows releases, including its new Vista operating system. Internet Explorer is the main attack vector for the exploits. Mozilla's open source browser Firefox also is at risk, but so far researchers haven't seen attacks focusing on it.
Microsoft released an emergency patch for the .ANI bug on April 3, shipping the fix a week before the company released its regularly scheduled monthly Patch Tuesday. The fix, however, didn't come out before hackers began exploiting the bug.
Researchers at Determina Security Research had alerted Microsoft about the vulnerability last December, but the company still hadn't pulled together a patch for it before the exploits came out more than three months later. Once the exploits hit -- and they hit fast and hard -- toward the end of March, Microsoft said it had nearly 100 technicians working around the clock for several days to get an emergency patch ready.
The bug, though, was familiar to some technicians at Microsoft, as well as to some researchers in the security community.
Researchers at eEye Digital Security found a .ANI flaw in Microsoft's Windows back in 2004 and reported it to the company, according to Andre Protas, a director at eEye, in a previous interview. Microsoft released a patch for it on Jan. 11, 2005.
Like this year, that .ANI bug resulted in a lot of exploits and trouble for IT managers. Craig Schmugar, virus research manager with McAfee's Anti-Virus Emergency Response Team, said the .ANI exploits spent quite a bit of time in his company's top-five exploit list. The exploits, then as today, were transport mechanisms for a variety of malware that infected users' computers.
Alexander Sotirov, a vulnerability researcher for Determina, was the one who reported the most recent .ANI vulnerability to Microsoft in December. It's "the same mistake," he said.
"In fact, that piece of code was almost 100% identical to the code fixed in the MS05-002 patch," he said. "However, the Microsoft patch did not fix this second instance of the vulnerability and Windows was still vulnerable to the attack."
So, if Microsoft created a patch for that .ANI bug back in 2005, why didn't it find and patch this most recent .ANI bug, which sits in the same binary file, just a few coding steps away from its vulnerability predecessor?
In his blog post, Howard ran through a lengthy list of security procedures that did not catch the bug. He talked about the lack of a GS cookie on the function stack, even though the code is compiled with GS. The GS is a buffer security check. The .ANI flaw was a buffer overrun problem.
"This is not the first time we've seen code with no cookie, and this has made us rethink the heuristics used by the compiler when it determines whether to place a cookie on the stack or not," wrote Howard. "But, 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 also talked about the analysis tools and how they do not flag the coding construct as a security bug because "it's a very low-priority warning, and is presently not an SDL 'must-fix' warning," he explained. "Why did our static analysis tools not find this bug? 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."
In responses to the blog post, Sotirov calls Howard on not facing the question of how Microsoft programmers could have missed the second .ANI bug when they were fixing the first one two years ago.
"You didn't answer the most interesting question: Why did Microsoft fail to find the MS07-017 vulnerability when you were working on the MS05-002 patch?" he wrote. "All you had to do was search the source code for all other places where the ReadChunk function was used (that's the function that actually does the memcpy). There are only three callers to it -- one of them is safe, one of them was the cause of MS05-002, and the third one [the cause] of MS07-017. This is exactly how I found the the MS07-017 bug -- I was actually looking at the changes in the MS05-002 patch and decided to look at the other callers to ReadChunk. The SDL process certainly requires you to audit the code for any related vulnerabilities. ... Why did it fail in this case?"
Another blog reader, though, gave Microsoft credit for tackling the question in a public forum.
"First off I would like to give Microsoft kudos for launching this blog and using it to educate developers on secure coding using real world examples," wrote the reader. "I always find real world problems sink in much deeper than contrived examples."