Opinion: Many operations fell short for the .ANI vulnerability to still be unpatched today. Microsoft: Let my patches go!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.
Researchers release a workaround for the zero-day Windows animated cursor vulnerability. Click here to read more.
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. "
A widespread malicious attack is posing as an invitation from Microsoft to download a beta version of Internet Explorer 7.0. Click here to read more.
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
