Security Researchers Say Windows .ANI Problem Surfaced Two Years AgoSecurity Researchers Say Windows .ANI Problem Surfaced Two Years Ago

Security researchers say the Windows .ANI bug that has been plaguing users for the past week first surfaced -- and was patched -- in early 2005.

Microsoft, however, says the .ANI vulnerability found this year is different from the one found years ago. But some security experts say it's the same mistake in the same process, and they're questioning how Microsoft could have missed it.

"If they had simply looked for other references for the same piece of code when they originally dealt with it a few years ago, they would have found this and patched it in 2005," said Craig Schmugar, a threat researcher with McAfee. "It would have saved a whole lot of people a lot of time, money, and effort."

Microsoft declined a telephone interview for this story, but a spokesman did e-mail information to say that while the two vulnerabilities are both related to cursor and icon format handling, each vulnerability is unique.

The .ANI vulnerability involves the way Windows handles animated cursor files. It's a buffer overflow problem. The flaw, which affects all recent Windows releases, including Windows Vista, could enable a hacker to remotely take control of an infected system. Internet Explorer is the main attack vector for the exploits. Researchers concluded this week that Mozilla's open source browser Firefox also is at risk, though exploits haven't been focusing on it.

While Determina researchers had alerted Microsoft about the current vulnerability in December, 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 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. It was shipped April 3.

Security researchers say the release of a patch won't stop the exploits. It won't even slow them down. In just a matter of days, analysts at Websense, a security company, found more than 700 Web sites that are spreading the .ANI exploit. Researchers also have found an exploit being sent out in a spam campaign that was luring users to malicious Web sites with promises of pictures of a naked Britney Spears. Automated toolkits began popping up online to let even lesser hackers build their own exploit malware.

Researchers at eEye Digital Security found a .ANI flaw in Microsoft's Windows back in 2004 and reported it to the company, said Andre Protas, a director at eEye, in an interview. Microsoft released a patch for it on Jan. 11, 2005.

Like today, that .ANI bug resulted in a lot of exploits and trouble for IT managers. McAfee's Schmugar 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.

Both vulnerabilities received a critical rating.

Alexander Sotirov, a vulnerability researcher for Determina Security Research, 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."

There were two instances of the flaw. One was found in 2004 and patched in 2005. The other instance wasn't identified and went unpatched until this week. Protas from eEye said the actual vulnerable code is identical. It's just in a different place in the operating system.

The researchers explained that the vulnerabilities deal with the same process: animated cursor handling. They're both buffer overflow problems. They're both in the same .ANI header parsing, specifically sitting in the user32.dll binary file. One was just a few coding steps away from the other.

What makes them different? The piece of flawed code that causes the trouble sits on one header in the first instance and on a second header in the other instance. Because of the difference in the headers, exploits for the vulnerabilities need to be crafted slightly differently to take advantage of the flaw.

"It's the same flawed code, just on one header as opposed to the other," said Protas. "There really isn't that much difference in these vulnerabilities. If a hacker knew the second vulnerability existed, he could have easily turned out an exploit for it."

Microsoft says those differences are enough to make these similar but entirely different vulnerabilities.

Each attack would have to be specially crafted, a Microsoft spokesman said. An attempt to exploit the flaw found in 2004 couldn't be used to successfully exploit the current flaw, and vice versa. "The attacks must be changed in order to be successful," he noted. "An attack would be similar only insofar as it would target cursor and icon format handling functionality in Windows. Microsoft strives to identify as many variants as possible in the surrounding code areas of reported issues and strives to deliver comprehensive security updates; however, Microsoft may not discover all unique variants. Microsoft is investigating why the vulnerability addressed [this week] wasn't previously addressed as part of [the 2005 patch] and will incorporate that learning into our processes."

McAfee's Schmugar challenges that position. "I'm sure they would say they fixed the problem in 2005 and this isn't the same thing," he said. "It's kind of splitting hairs."

Sotirov said the second instance of the flaw was easy to find and he can't figure out why Microsoft simply didn't do it. "Microsoft uses a development methodology called Security Development Lifecycle, which emphasizes the need to audit related code when fixing a vulnerability," noted Sotirov. "Programmers are generally very consistent in their coding, so you often see the same kind of mistake repeated over and over again in parts of the source code that are similar to each other. If I could find other copies of the code that reads ANI file data, there was a good chance that they would contain the same vulnerability."

He added that it took him about two hours to find the second .ANI flaw and it would have taken less time if he'd had access to the Windows source code.

"Is it reasonable to expect that during the auditing and patching of [the first] vulnerability, this other one [should have been] discovered and dealt with at the same time?" asked Schmugar. "In this case, I'd say it would have been reasonable for this to be caught. Because of the nature of this, we can expect other researchers, and hackers, to be evaluating other patches to see if there are other similarities that need to be fixed."