From: mike 



http://www.eweek.com/article2/0,1895,2110151,00.asp



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

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


 /m

--- BBBS/NT v4.01 Flag-5