Text 17345, 126 rader
Skriven 2007-04-10 17:45:12 av mike (1:379/45)
Ärende: Better Hope That the ANI Attacks Pass over Your Computer
================================================================
From: mike <mike@barkto.com>



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
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)