"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."