eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
There are many reasons to be disappointed in Microsoft over the .ANI vulnerability that is the talk of the security community the last few days. The analysis of the bug and its history speak badly of Microsoft’s efforts in many ways: The company’s patching practices came up short, its security protection technologies came up short, and its code analysis was shoddy. There are many reasons why this should never have happened, and now we should all be upset about it.
Before we go any further, please note that on Tuesday, April 3, Microsoft is releasing an “out of cycle” patch for this bug. It will certainly be available through all the usual channels: Windows Update, Microsoft Update, SUS, Download Center, etc. APPLY IT AS SOON AS POSSIBLE. If you’re concerned about side effects, bear in mind that we’re talking about animated cursors here: Who cares if the break?
The most glaring problem is the fact that Microsoft was informed of this vulnerability on Dec. 20, 2006, by Determina. It’s April now and Microsoft released no updates last month. It’s possible that the company is planning to wait for the April patch day (April 10), but my guess is that a patch will be coming out “out of cycle” the way they did for the WMF bug.
What can possibly take this long? Almost within hours, eEye had a mitigation patch out that prevents cursors from loading anywhere except %SYSTEMROOT%. This is, of course, far from perfect, but it’s an effective mitigation. Why didn’t Microsoft have something like this available?
It’s reasonable for Microsoft to take time testing security updates to make sure they don’t cause problems. This is a trade-off, and the fact that sometimes there are problems anyway proves that there’s always a reason to do more testing. But when Microsoft takes several months like this to fix a really serious bug, it runs a serious risk. It should at least have some less-than-perfect option available for users, like eEye’s patch.
If you didn’t want to apply a third-party patch, and of course Microsoft tells you that it can’t endorse such things, there are steps you can take to mitigate it. In this case the steps are unsatisfying and, in some cases, confusing. When Microsoft tells you, “As a best practice, users should always exercise extreme caution when opening or viewing unsolicited e-mails and e-mail attachments from both known and unknown sources,” what are we to make of this? You can’t always know an e-mail was unsolicited until you read it. Should we stop reading e-mail until there is a patch?
All of this points to the need for Microsoft to re-evaluate its update prioritization. One of the things about testing is that you can generally speed it up with more resources. Maybe Microsoft needs to throw more resources at update testing. Heaven knows, the company can afford it.
The second great failing at Microsoft goes back over two years to the MS05-002 patch for the frighteningly similar “Vulnerability in Cursor and Icon Format Handling Could Allow Remote Code Execution.” It’s similar because it’s essentially the same bug. This bug was reported by eEye Nov. 15, 2004, and patched (pretty quick for Microsoft) on Jan. 11, 2005.
Read the Determina advisory on the new bug for gory technical detail, but in retrospect Microsoft should have found the new bug once it learned about the old bug. Basically it fixed the flaw where the ANI file had an “anih” block with an overflow, but not in the case where there were two anih blocks with an overflow on the second.
The only thing I can say in fairness to Microsoft is that eEye seems to have missed this “second anih block” problem in its analysis too, but Microsoft has the source code and eEye doesn’t. It seems reasonable that when a major, naive bug is found in a section of code (and the MS05-002 bug was a classic stack overflow, one that should never have survived a security audit), you take the time to scrutinize the rest of the code in the same program. If Microsoft had done that, there’s at least a good chance it would have found this new problem. (And if it did do an analysis and didn’t find the problem, well perhaps that’s even worse.)
Next page: The third failure.
The third failure is in stack protection. I’m sure I wasn’t the only one who was confused to hear that this was a stack overflow and that it affected Windows XP SP2 and Windows Vista. Weren’t those operating systems compiled with the /GS switch, which adds stack protection code in order to prevent overflows like this?
Well, sort of. Yes, they were compiled with /GS, but it turns out that /GS doesn’t do all that you might have thought it did. Thanks again to the Determina advisory for explaining that /GS only adds stack protection code when a function uses certain types of arrays, on the assumption that buffer overflows derive from out-of-bounds array access. Since the ANI handling code uses a C struct rather than an array, no protection is provided.
The Microsoft docs for the /GS switch describe it this way: “The compiler injects checks in functions with local string buffers or, on x86, functions with exception handling. A string buffer is defined as an array whose element size is one or two bytes, and where the size of the whole array is at least five bytes, or, any buffer allocated with _alloca.” They don’t try to hide it: “/GS does not protect against all buffer overrun security attacks. “
Once again, obviously an engineering trade-off decision was made. Perhaps Microsoft was concerned that putting in stack checking literally everywhere would fatten the program up beyond what was acceptable. Its compiler, its source code, it could do the testing to see. This is the case where the decision works badly for Microsoft. It seems to me that maybe there’s a need for a /GSP (for “Paranoid”) switch that puts in the stack check even if there doesn’t seem to be a need, unless there’s a good reason not to (there are cases, described by Microsoft, where the stack check code wouldn’t be reliable).
I don’t often get this mad at a vendor. I’m usually more inclined to feel sorry for them for all the grief they’ll take when they screw up, but Microsoft deserves massive grief from this. Like the WMF bug, this is likely to be an endemic attack for years to come, lurking around the background of the Internet, and it needn’t have happened.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.com’s Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s Weblog.
More from Larry Seltzer